Improving connection times in LANSA Open
|Abstract:||Factors that have an influence in the time it takes in opening a LANSA Open session|
|Submitted By:||LANSA Technical Support|
A connection between the PC and the host is established during the OpenSesssion. Each L/Server session starts an iSeries job running in batch mode. The time it takes for a connection to complete depends on a combination of three factors:
- Number of fields and files used (declared) in the session to be opened.
- The priority that the iSeries started batch jobs are running under. The priority is determined by the class associated with a subsystem's routing entry. Usually, jobs started in subsystem QBATCH run at priority 50, QINTER ones at priority 20. Using the L/Server API LceUsePriority it is possible to overwrite this value. Thus, a job started in QBATCH which would normally run at a certain priority, using LceUsePriority could be started with a higher priority. This would result in faster response times in general, notably while the first connection is established.
Note: the connected user must have the required authority to effectively have the priority changed. Refer to the user profile definition parameters on the iSeries: user class, group profile, special authorities, etc. and to the iSeries's system security level setting (QSECURITY system value).
If the user didn't have the appropriate authority to change job run priorities, the job will still start but would run with the priority unchanged. To verify that the priority has effectively changed:
A) On the iSeries, execute the command WRKACTJOB.
B) Use option 5=Work with job against the L/Server job started on the iSeries.
C) Use option 3 to display the job runtime attributes.
- The iSeries workload (iSeries model is also important, e.g. CISC vs. RISC, etc.) at the time the connection is attempted. This may vary from one day to another and even on the same day. Typically, slow connections are to be expected in the morning if a number of users all connect at the same time.
The Use Local Data Dictionary option:
LANSA Open "knows" about the repository information stored on the iSeries by loading the file and field definitions into memory. This is achieved in two ways that also influence the connection response time. This setting is specified in either the LANSA.INI file for the 16 bit version and using the LANSA Open configuration utility for the 32 bit version of LANSA Open.
- Use Local Data Dictionary = No.
When the open session request is sent to the host, file and field definitions are retrieved from the host repository and loaded into memory for further use by the application. This is the slowest method because the repository definitions are retrieved every single time an open session is issued.
- Use Local Data Dictionary = Yes.
When the open session request is sent to the host, file and field definitions are retrieved from the host repository and stored in the local hard drive. The very first open session will take longer as the local dictionary does not exist and it has to be built. Subsequent open sessions will only verify whether both repositories, the host and the local one, are in sync (are the local file and field definitions still the same as the hosts ?). This "version checking" is very fast. Should any definition be different, a re-build of the local data dictionary will take place to reflect the changes.