AS/400® Prestart Jobs for OneWorld®
AS/400® Prestart Jobs for OneWorld®
Primary Contact/Author / Dave AndersonTechnical Writer / Doug Keckler
Technology Demographic Table
Product / OneWorld
Version / All
Platform/OS / AS/400®
Industry / All
Application / All
Database / DB/2
Key words / Prestart jobs, QZDASOINIT, Performance
Date / May 2001
Executive Summary
The implementation of a prestart job for each ODBC connection from OneWorld to the AS/400 can significantly improve performance. Not only will performance be improved for the period when everyone signs on for the day but also during the day as connections are dropped and restarted. This document explains the reasons to use prestart jobs as well as describes the proper parameters to use to achieve the best performance.
Running Jobs on the AS/400
The high level implementation of the AS/400 hardware leads to a very high level of system reliability. One of the chief reasons for this is that each job is an entity unto itself. Many common errors on other systems are impossible on the AS/400. For example, each job on the AS/400 conceptually runs in its own address space. Furthermore, since the system never addresses memory by actual location it is impossible to branch to a memory location outside of a jobs address boundary. Another unique concept in the AS/400 implementation is that every object touched is always checked for security. This also is controlled at the job level.
The downside of the AS/400 implementation in hardware is performance. This is particularly evident during job initiation. Approximately 80 disk I/O accesses are required to set up a job structure, which is approximately 20 times the workload performed on other operating systems. Since this workload is so intensive, different techniques have been developed for different types of programs to minimize the effects of the CPU intensive job initiation.
The ideal design of an AS/400 job is to have a single job accomplish as much as possible. Early AS/400 interactive programs tended to be huge since the cost of job-to-job transition was so high. The style of programming evolved into sharing of information from a preceding job so that a new job is not penalized with as much job initiation work. This style of programming involved having a front-end program that opened all of the database files at the highest level of usage that would be encountered during the course of the entire series of job steps. Subsequent programs then attached to the shared, already open data access control block.
Client/server applications directly conflict with the goal of having relatively few jobs running for a long period of time. Instead, each ODBC connection to the database is a separate unique job. A typical OneWorld application will have from 6 to 12 connections to the AS/400 database. Each data source implements a separate ODBC connection. In addition, if translation of the data is not desired, a DNT (do not translate) data source is also created.
Prestart Jobs on the AS/400
The concept of a prestart job was implemented on the AS/400 to time shift the startup workload associated with job initiation. Prestart jobs on the AS/400 perform as much work as possible when the job is initiated. The prestart job is then put into a pool of jobs eligible to be used by the next job requestor. When the requestor requests to connect to the prestart job, only the final steps of job initiation are completed, utilizing less than 20 percent of the workload normally required to initiate a job. This concept does not reduce the amount of work to be performed but only shifts the time when the work is done. The goal of using prestart jobs is to shift the work from synchronous in-line work (required when the user requests it) to asynchronous work performed in advance. Thus, the user sees a significant reduction in response time for the first usage of a data source.
Another advantage in the use of prestart jobs occurs when many users all sign on the system at approximately the same time (such as 8:00AM). Without prestart jobs, system performance can suffer for as long as two hours until the system finally catches up with the work desired.
The downside of using prestart jobs is that temporary storage is required to store all of the job structures. This temporary storage requirement could result in the need for additional disk drives. Another potential disadvantage is that the startup and shutdown of the subsystem that contains these prestart jobs will be longer.
Preliminary performance testing indicates that performance is not noticeably improved when using fewer prestart jobs by combining the number of connections. However, when performing large-scale benchmarks involving as many as 25,000 connections, significant time was saved in the startup and shutdown of the subsystem.
Implementing Prestart Jobs
To implement prestart jobs for ODBC connections to the AS/400 using Client Access Express, the QZDASOINIT program in the QSERVER subsystem should run as a prestart job. A typical OneWorld application will have from 6 to as many as 12 connections to the AS/400 database. To determine the number of prestart jobs to use the display active prestart job command is executed. DSPACTPJ SBS(QSERVER) PGM(QIWS/QZDASOINIT) This command shows both the current number of active prestart job entries and the peak number reached. The display also shows if jobs were queued up starting. The number of jobs to prestart should be equal or greater than the peak number.
Note: See the “Reference When Making Changes to QSERVER” section of this document for important information regarding QSERVER.
An example of this display is as follows:
********************************************************************************
Display Active Prestart Jobs DENAS10
04/24/01 13:02:24
Subsystem . . . . . : QSERVER Reset date . . . . . : 04/24/01
Program ...... : QZDASOINIT Reset time . . . . . : 12:08:03
Library . . . . . : QIWS Elapsed time . . . . : 0000:54:21
Prestart jobs:
Current number ...... : 845
Average number ...... : 251.6
Peak number ...... : 850
Prestart jobs in use:
Current number ...... : 839
Average number ...... : 247.7
Peak number ...... : 847
Program start requests:
Current number waiting ...... : 0
Average number waiting ...... : .0
Peak number waiting ...... : 1
Average wait time ...... : 00:00:00.0
Number accepted ...... : 1649
Number rejected ...... : 0
********************************************************************************
Once the number of prestart jobs is determined it is simply a matter of making the changes to the QSERVER subsystem. This can be done while the subsystem is active. The easiest method of making these changes is to perform a WRKSBSD QSERVER. Choose option 10 to display the prestart jobs and select QZDASOINIT in QIWS. You can change the values the using the following command.
CHGPJE SBSD(QSERVER) PGM(QIWS/QZDASOINIT) STRJOBS(*YES) INLJOBS(850) THRESHOLD(25) ADLJOBS(50) MAXJOBS(*NOMAX) MAXUSE(200)
An example of this display follows:
********************************************************************************
Subsystem description: QSERVER Status: ACTIVE
Program ...... : QZDASOINIT
Library ...... : QIWS
User profile ...... : QUSER
Job ...... : QZDASOINIT
Job description ...... : *USRPRF
Library ...... :
Start jobs ...... : *YES
Initial number of jobs ...... : 850
Threshold ...... : 25
Additional number of jobs ...... : 50
Maximum number of jobs ...... : *NOMAX
Maximum number of uses ...... : 200
Wait for job ...... : *YES
Pool identifier ...... : 1
********************************************************************************
Some of the more significant parameters are discussed below.
If you want the QZDASOINIT jobs to be started in advance, set “Start jobs=*YES.” This starts the “Initial number of jobs” specified when the subsystem starts. Thus, the 850 jobs specified would accommodate approximately 850/8 or about 106 users assuming each user has 8 connections. If all users used 8 connections each, when the 107th user signs on, connections 825 thru 832 are used. When connection 825 is reached, an additional 50 jobs are started asynchronously since the threshold (850 – 25) is reached. Some people feel that the threshold should be set so that the next to last user will trigger enough connections for only one additional user. In this example the threshold would be set to 16 and the additional number of jobs would be set to 8. I personally believe that slightly greater numbers should be used.
If a user signs on once a day and the subsystem is restarted each night, the number of connections would simply increase all day and then decrease as they sign off. However, OneWorld is not quite this simple under the covers since a transaction boundary is currently forcing a connection to be stopped and restarted with different commitment control settings. An example of an application using a transaction boundary is the final OK button in Sales Order Entry. Thus, connections are being dropped and restarted. For the next release of OneWorld, connection pooling will be implemented.
The “Maximum number of uses” parameter determines if a connection can be reused or if a new job needs to be started when the connection is dropped. If the connection can be reused (by either the same user or a different user), then significantly less work is performed. This is the reason that the default is set to reuse a connection 200 times. If the connection is reused, the job log for that active connection contains information from each of the 200 uses of the connection. This can make it very confusing to find the debug information in the active connections. For debugging purposes, the “Maximum number of uses” should be set to 1, which causes the job to end and an AS/400 job log to be created. When running in this mode the performance is similar to not using prestart jobs. Once the problem is found the “Maximum number of uses” should be reset to 200.
Another instance in which the “Maximum number of uses” could be set to 1 is to improve performance when connections are terminating abnormally. For example, a frequent cause of abnormal termination is that users are powering off their PC’s without terminating OneWorld because they have accidentally requested a long running query. When this happens, the temporary workspace is not always cleaned up for the preceding connection. If this happens frequently, it causes the disk space on the AS/400 to be rapidly consumed by temporary objects that are no longer needed, which in turn causes the AS/400 to slow down since the processing requirements for failed connections increases. Again, once the cause of the abnormal termination is found, the maximum number of connections should be set back to 200.
Normally, each connection takes approximately 4.9MB of temporary storage. Additional temporary storage is allocated if the connection is performing a SQL statement that creates a temporary work file (e.g., a QBE with a wildcard of *xx). You can confirm this by reviewing the call stack of the QZDASOINIT job. If you see a QQTSORT module, then the user is building a temporary sort of the table and temporary storage is required to produce the query results. Since a minimum of 4.9MB temporary storage is allocated to create each QZDASOINIT job, the number of connections should not be set higher than is normally used or the AS/400 will start to terminate connections. Every 5 minutes the operating system checks to see if there is an excess of pre-start jobs that are not being used. If there is, then the AS/400 will gradually start ending the extra jobs up to the point where the number of jobs is at the initial start setting.
With V4R4, the maximum preset jobs value has been increased to 9,999. Prior to V4R4, the maximum value allowed for the number of prestart jobs was 1,000 via the screen interface. If a larger number is needed for a previous release, see J.D. Edwards OneWorld Tuning Guide for the iSeries 400 at
http://www-1.ibm.com/servers/eserver/iseries/service/bms/pdf/oneworldtuning.pdf
Normally it is desirable to start up connections when the subsystem is started. Usually you would do this during an off peak hour (e.g., 2:00AM) and the processing workload can be easily absorbed by the system since little is running. If these connections are not started during an off peak time, the system will run slower when users sign on for the day. This slow operation can continue for as long as two hours if most of the users sign on at about the same time. Timing of the start of this subsystem should be a consideration since, as mentioned earlier in this document, the operating system monitors QZDASOINIT jobs that are not being used and ends them within a time frame.
Troubleshooting Prestart Jobs
If Client Access Express is used for the ODBC connection to the AS/400, the program to run as a prestart job is QZDASOINIT in the QSERVER subsystem. If the prestart jobs are running correctly, the job type for the job should be PJ (prestart job) and not BCI (batch immediate). The job type displays in the job display including the work with subsystem jobs command (WRKSBSJOB) and in the work active job command (WRKACTJOB). If the job type appears as BCI for QZDASOINIT then a lock was probably held from a previous backup that was performed with QSERVER still active. In this case, none of the advantages of a prestart job are gained.