Performance tips for prestart jobs

The prestart job should do as much work as possible before it attempts to acquire an ICF program device or accept a CPI Communications conversation. The more work it does initially (allocating objects, opening database files, and so on), the less it will need to do when a program start request is received, therefore giving the transaction faster response time. The following are some additional performance considerations when using prestart jobs:

Remember: If an active prestart job entry is in the subsystem, the subsystem periodically checks the number of prestart jobs in a pool that are ready to service program start requests to determine if there are excessive available prestart jobs. Excessive available prestart jobs are ended by the subsystem gradually. However, the subsystem always leaves at least the number of prestart jobs specified in the INLJOBS attribute in a pool.

You should only deallocate resources specific to the transaction that you want performed. Any resource that is commonly used for other transactions performed by the prestart job program should remain allocated while the job is waiting for its next request. You should leave files open and objects allocated to save time when the next request is received.
Note: Database files that are left open in the prestart job generally require the same considerations as database files that are shared in the same job.
Since the same QTEMP library is used for the entire life of a prestart job, objects that are no longer needed should be deleted.
Since the same Local Data Area (LDA) is used for the entire life of a prestart job, information can be kept and passed to the next transaction.
Since each prestart job can handle many program start requests, and has only one job log, you may want your application to send messages to the job log identifying the activity of the prestart job. This is also useful because the job logs of batch prestart jobs are cleared between uses.
The job attributes of a prestart job are not changed by the subsystem when a program start request attaches to a prestart job. The change Prestart Job (CHGPJ) command allows the prestart job to change some of the job attributes to those of the job description (specified in the job description associated with the user profile of the program start request or in the job description specified in the prestart job entry.)
If your system uses job accounting, the prestart job program should run the CHGPJ command with the program start request value for the accounting code parameter (CHGPJ ACGCDE(*PGMSTRRQS)) immediately after the program start request attaches to the prestart job. This action changes the accounting code to the value specified in the user profile associated with the program start request. Immediately before the program finishes handling the program start request, the program should run the CHGPJ command with the Prestart Job Entry value for the accounting code parameter (CHGPJ ACGCDE(*PJE)). This changes the accounting code back to the value specified in the job description of the prestart job entry.
The class (CLS) parameter on the prestart job entry provides a way to control the performance characteristics of two classes of prestart jobs per prestart job entry. For example, you can provide a lower execution priority for work that arrives when the system is already busy.