The work-management team recently made available some changes with PTFs to help control the behavior of job creation for cases when a program may get in a loop submitting jobs. The change made with the PTF is to slow down the creation of new jobs when the system is approaching the limit for the maximum number of jobs (QMAXJOB system value). This support is in the base operating system in 7.1 and later releases.
QMAXJOB defines how many jobs can be on the system and includes all jobs: jobs submitted to a job queue, active jobs and ended jobs with spooled output. When the system reaches the limit specified by QMAXJOB, no more jobs can be started and the system can become inoperable.
There’s a warning message–CPI1468 “System job tables nearing capacity”—that’s sent to QSYSOPR when the system is nearing the limit of the maximum number of jobs. Support was added to customize when these messages are sent with the following PTFs:
• 6.1 – SI30171
• 5.4 – SI29585
• This same function exists in 7.1 and later without additional PTFs
By default, the CPI1468 is sent when the job tables are 90-percent full. In some situations, that’s too late and you don’t have time to recover from the condition. Create a data area named QMAXJOBPCT in QSYS with the desired percentage value at which you want the message to be sent. For example:
TYPE(*DEC) LEN(2 0) VALUE(70)
After the data area is created or changed, to force the change to take effect immediately do one of the following:
- IPL the system (rather dramatic)
- Change QMAXJOB system value
With these PTFs, the system adds delays to starting new jobs when the number of jobs is at 90 percent of the QMAXJOB setting. Override this percentage by creating a data named QWTSBSDLY in QSYS; for example, you could have the threshold be set to 80 percent. There are no delays if the number of jobs in the system remains below that percentage.
TYPE(*DEC) LEN(3 0)
TEXT('Theshold for delays when creating jobs.')
The delays start at a half second, but are increased as the system approaches the QMAXJOB limit. A single delay isn’t noticeable, but if you have a job that’s looping starting jobs, these delays can add up and offer some protection to keep the system operational as you approach the QMAXJOB limit. You can still run out of job-table entries, but it will take longer and you’ll have a little more time to react to the situation.
In 2008, we wrote a Redpaper, “Best Practices for Managing IBM i Jobs and Output (and a few other special tips)“. This Redpaper covers general recommendations for improved management of jobs and output. Provided in that Redpaper is a sample CL program source for a Submit Job (SMBJOB) exit program. The submit job exit program is the best way to control the runaway submission of many jobs.
Another set of PTFs were provided that change the default behavior of the system to briefly display the end-of-job display when an interactive job ends. Previously, when an interactive job was ended, the end-of-job display would remain until the user pressed enter or 30 seconds had passed. With these PTFs, this delay is removed and the interactive jobs are ended immediately without delay due to the end-of-job message; the message is still sent, but is only seen briefly. This change is helpful for ENDSBS, for example. Prior to the PTFs, ending an interactive subsystem would generally not end the jobs right away because the end-of-job display would be displayed for 30 seconds for those jobs where the user didn’t press enter. With these PTFs, the jobs are ended right away.
These PTFs are:
The PTF cover letters containing documentation on how to create a data area named QWTEOJDSP in QSYS to get the old behavior back.
This blog post was edited for currency on February 1, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.