Admin Alert: Using OS/400 Prestart Jobs for Repetitious Server Processing

April 6, 2005 Joe Hertvik

In a previous column, I discussed using OS/400 autostart jobs to run server jobs that handle repetitious processing for system users. With OS/400 being the full-featured operating system that it is, there’s more than one way to skin this particular cat. OS/400 also provides a second and, in some ways, a more effective way to automatically start repetitious server jobs in a subsystem: prestart job entries and prestart jobs.

Like autostart jobs, a prestart job is a batch job that is usually configured to start running when a subsystem begins. But unlike autostart jobs, prestart jobs can easily be started and stopped on demand without bringing the entire subsystem down. Prestart jobs can also be configured to spawn additional copies of themselves to handle increased demand, and each individual prestart job can be timed to expire and spawn a successor copy after a set number of uses. OS/400 traditionally uses prestart jobs to handle communication functions, such as when large numbers of ODBC and JDBC users access data through the QZDASOINIT jobs in the QUSRWRK subsystem, but they can also be used to handle persistent single-threaded server jobs that continually process data throughout the day.

Prestart jobs are configured by using the Add Prestart Job Entry command (ADDPJE) to add a prestart job entry to a subsystem. Whenever the subsystem starts or whenever a prestart job entry is added to a subsystem, the subsystem starts enough of its designated prestart jobs to handle the expected demand the entry was configured for. For example, if I wanted to add a prestart job entry to start three communications jobs whenever the QSYSWRK subsystem starts, I could enter the following command:

ADDPJE SBSD(QSYSWRK) PGM(PGM_NAME) USER(USER_NAME) INLJOBS(3) THRESHOLD(2) ADLJOBS(2) MAXJOBS(200) JOBD(JOB_DESC) MAXUSE(200) CLS(CLASS_NAME)

There are a number of values to consider for any prestart job entry, but here are the critical parameters to enter:

• Subsystem (SBSD): The name of the subsystem that your prestart jobs will run in. This is a mandatory parameter.
• Program Name and Library (PGM): The name and location of the program that runs in this set of prestart jobs. This is another mandatory parameter.
• User Name (USER): The name of the OS/400 user profile under which the prestart job programs will run. This is an optional parameter that will default to the QUSER user, if no field name is entered.
• Initial Number of Jobs (INLJOBS): This field specifies the initial number of copies of the prestart job program (as specified in the PGM parameter) that will be started when the subsystem starts. The default value is three copies, but you can enter any number between 1 and 9999. This value is traditionally used to prestart a number of communication jobs that will be up and ready to use when remote users access the system, saving those users the overhead that would normally be associated with starting a communications server job.
• Threshold (THRESHOLD): This parameter tells OS/400 when the subsystem should spawn additional copies of the prestart job to service more users. When the number of available copies of the prestart job (those copies that aren’t in use by a user) falls below this number, the subsystem will spawn new copies of the prestart job to handle increased demand. The default value is 2.
• Additional Number of Jobs (ADLJOBS): This value tells the subsystem how many additional prestart jobs to spawn when the number of available jobs falls below the threshold. In this example, when there are fewer than two prestart jobs available, the subsystem will spawn an additional two jobs to handle more demand. The default ADLJOBS value is 2.
• Maximum Number of Jobs (MAXJOBS): This is the upper limit on the number of prestart jobs that can be spawned in a subsystem for a particular Prestart Job entry. The default value is *NOMAX, which means that, given enough demand, the subsystem can spawn as many additional prestart jobs as it needs. You can also set MAXJOBS to a value between 1 and 9999.
• Job Description (JOBD): The job description you want OS/400 to use when running these prestart jobs. The JOBD parameter serves the same purpose as it does for the autostart jobs I discussed in that previous column, but prestart job activation ignores the Request Data or Command parameter of the job description. The default value is to use the job description that is normally associated with the user profile the jobs will run under.
• Maximum Number of Uses (MAXUSE): MAXUSE designates how many times a prestart job can be accessed by a user before it is ended and another prestart job is spawned to take its place. The default is 200, but you can set MAXUSE to any value between 1 and 1000, or you can set MAXUSE to *NOMAX, which means your prestart jobs will never expire.
• Class (CLASS): Specifies the name and location of the class that the prestart jobs run under. A class defines the run priority, time slice, wait time, and other processing attributes of each running prestart job. The default value is *SBSD, which tells OS/400 to use the class associated with the subsystem the prestart jobs will run in.

Once these parameters are entered and the prestart job entry is added to the subsystem, the defined set of prestart jobs will immediately begin running in your subsystem. You do not have to stop and restart the subsystem to activate your jobs. The name of the prestart job entry for the subsystem will be the program name specified in the PGM parameter.

The number of prestart jobs that are initially started in your subsystem is equal to the value in the INLJOB parameter of the Prestart Job entry that was created. Each job is started with the run-time values specified in the PGM, USER, JOBD, and CLASS parameters, and all prestart jobs have a job type of PJ. When the number of prestart jobs in use falls below the THRESHOLD parameter, the number of prestart jobs specified in the ADLJOBS parameter is added to the subsystem. The subsystem ends each prestart job when it has been used more often than the number of times listed in the MAXUSE parameter. A prestart job entry packs a lot of processing into a subsystem description.

You can view your new prestart job entry by running the Display Subsystem Description command (DSPSBSD), as shown below, and selecting option 10, Prestart Job Entries, from the menu that appears:

DSPSBSD SBSD(LIBRARY/SUBSYSTEM)

To change the parameters that your prestart jobs use, run the Change Prestart Job Entry command (CHGPJE) as follows and press F4 to prompt for the values you can change:

CHGPJE SBSD(SUBSYSTEM) PGM(PGM_NAME)

To remove a prestart job entry from a subsystem, you can use the Remove Prestart Job Entry (RMVPJE) command as follows:

RMVPJE SBSD(SUBSYSTEM) PGM(PGM_NAME)

Prestart job groups can also be stopped and restarted while a subsystem is running. To end all the PJ jobs running for a particular prestart job entry, run the End Prestart Jobs command (ENDPJ) as follows:

ENDPJ SBS(SUBSYSTEM) PGM(PGM_NAME)

If you prompt the ENDPJ command, you can tweak the end parameters to specify whether the prestart jobs should be ended in a controlled manner or whether they should be ended immediately. There are a few other parameters you can also tweak for ending prestart jobs.

To start a set of prestart jobs while the subsystem is running, you can use the Start Prestart Jobs command (STRPJ), as follows:

STRPJ SBS(SUBSYSTEM) PGM(PGM_NAME)

And this will restart all the prestart jobs defined for a particular prestart job entry.

If you don’t want to spawn multiple prestart jobs at one time, you can also set up a prestart job entry that only launches a single server job in a subsystem. This type of prestart job can be set up so it doesn’t terminate until the subsystem ends or until the ENDPJ command is executed. To configure a prestart job entry to launch a single prestart job with no spawning of additional jobs, run the ADDPJE entry this way:

ADDPJE SBSD(QSYSWRK) PGM(QGPL/PGM_NAME) USER(USER_NAME) INLJOBS(1) THRESHOLD(1) ADLJOBS(0) MAXJOBS(1) JOBD(JOB_DESC) MAXUSE(*NOMAX) CLS(CLASS_NAME)

By creating a prestart job entry this way, you will always start only one job for your entry (INLJOBS = 1) that will never fall below its threshold (THRESHOLD = 1) and that will never add any additional jobs (MAXJOBS =1). In addition, this job has no maximum number of uses, and it will run until it is ended through an ENDPJ command, the subsystem ending, or a program error (MAXUSE = *NOMAX). So you can also use prestart job entries to automatically run single use server jobs that do not naturally end or spawn their replacement jobs.

Click here to contact Joe Hertvik by e-mail.