This section describes some best practices for modeling host applications. Click one of the following for more information:
Thoroughly review the host application
At this stage, take advantage of host system "power users" (more than one person if possible) to cover these questions:
Determine the Number of Models Needed
You cannot access more than one host application with one model. If the application you want to develop needs to access data from more than one host application, you must create two models and develop an application that can share variables, which will allow you to integrate host data from two or more Host Integrator models.
As a common practice, you should avoid using both schemes together in one model because entity navigation paths and cursor positions can become out of synch.
Use tables to manipulate host application data
There is less processing overhead using tables, because there is only one " round trip" needed to the server. Also, using SQL reduces the amount of coding necessary.
Set naming conventions
Determine global settings
Create concise operations
Break large operations into a sequence of smaller operations, using alternate and intermediate destinations.
Minimize patterns that identify an entity
Create patterns at the top and bottom of each entity to ensure the entire screen is displayed before the next process is taken, but do not add more patterns than necessary as this adds to the processing time to recognize an entity.
Parameters and Constants
Timing for 5250 Models
When creating 5250 based models, define patterns for each of the input fields on the sign-on screen and on any screen where the timing of screen recognition is difficult because the AS400 sends multiple writes to create the screen. To set up input field patterns:
By defining these patterns for the input fields, the screen recognition process
waits until these fields are ready for input. This ensures proper screen recognition
and enhances model performance.
After you have completed your model, take these steps to prepare the model for optimum performance before deploying it to Host Integrator Server.
Delete unnecessary entities
Your model should include only entities that contain necessary data or those that are intermediaries between entities containing this data.
Do not create an entity for a host blank screen unless you have exhausted all other options. Blank screens can have the potential of producing run-time entity signature ambiguity that could crash a session.
Delete unnecessary or unused attributes
Make sure that the attributes of each entity contain necessary data or input fields. This will improve performance and reduce memory consumption.
Delete all unnecessary operations
Validate the paths between entities to ensure they are traversable by the shortest route.
Reduce the screen signature
Review the screen signature of every entity in the model and reduce it to the minimum number of patterns required to uniquely identify the entity.
Optimize Traversal Operations
Before deploying the model, make sure the traversal operations are as efficient as possible. Open the model in off-line mode and follow these steps to review the operations for each entity:
Validate the model
Use Validator to validate your model and identify any possible error conditions.
Use Web Builder to Create a Web Client
Use Web Builder to quickly and easily generate a web application of the host application model. Use this application to test your model functionality.
Test possible error conditions for each operation
For every operation, test all possible error conditions by inputting bad data or reproducing mainframe error conditions.
Test the model parameters
Recognizing Screens as Entities
Invariably, your application will contain one or two screens that prove difficult to model. Problems range from unpredictable host data transmission timings to the host redrawing seemingly static portions of the screen. With these screens, it will take a little bit of extra observation and experimentation to model accurately. Evaluate the order in which the host writes the screen. Watch the behavior of the cursor. Use model debug messages to look for events that could be causing the problem.
Synchronizing with the Host
Getting out of sync with your host is one of the most common problems encountered when modeling host applications. If your model works well in the Design Tool, but seems to malfunction in the server environment, the lack of synchronization is the most likely reason. Host sessions running on a Host Integrator Server run faster than those in the Design Tool because there is no display to update. Therefore, the server can expose synchronization problems that don't appear in the Design Tool.
This advice applies particularly to operations that scroll recordsets or perform other tasks within a single screen. Even on block mode host applications, Host Integrator will sometimes try to perform operations too quickly, producing incorrect results. See Host Integrator Synchronization Techniques for more information.
In character mode applications, the host is constantly moving the cursor to write data, so just waiting for the cursor to end up in the correct position after a host update may be sufficient. If the cursor is placed in varying positions but in the same place relative to some text, then a WaitFor command is recommended.
To ensure synchronization, end all operations with an appropriate WaitFor command. See Host Integrator Synchronization Techniques for more information.