Last week, I wrote about detaching spooled files. As I was writing that article, I started to describe the IBM i job structures. It became apparent that there was too much information for that one blog, so this week I’ll review IBM i job structures.
There is little formal documentation on job structures. You can find bits and pieces in the Knowledge Center if you look at the documentation for the Display Job Table (DSPJOBTBL) command or the Create Job Structures API. The Display Job Table online command help (‘green screen’ help) probably has the most information regarding job structures.
Every job on the system has three main pieces that I generally refer to as “job structures”:
- an entry for the job in the job table
- permanent job structures
- temporary job structures
The “job table” is also called the “work control block table” and is the primary data structure used to keep track of all jobs in the system. Jobs on job queues, active jobs and ended jobs with spooled output all consume an entry in the job table. The job table is of limited size and can hold a maximum of 485,000 entries (pre 7.3), or 970,000 (7.3 and later); thus the upper limit on the Maximum Number of Jobs (QMAXJOB) system value. It’s not a good idea to run near the maximum number of jobs, as I described last week. The system job table should be kept to a reasonable size, and if you generally have a consistent number of jobs, the system will automatically do this for you.
The system has a built-in notification mechanism for when the job table is nearing its maximum capacity, as configured by the QMAXJOB system value. By default, the system will send the CPI1468 message (“System job tables nearing capacity”) to the QSYSOPR message queue (and to the QSYSMSG message queue if it exists) when the job tables are 90 percent full. IBM has provided the capability to customize the percentage at which this message is sent. You create a data area named QMAXJOBPCT in QSYS to control the percentage at which you want the warning message to be sent. Blog post Additional Work Management Controls reviews this feature.
If you have a ‘run-away’ job situation occur where you have many more jobs than is typical, you may want to consider compressing the job table. This is an action that is done at IPL and can be long-running. You should only do this when necessary. The system IPL attribute of Compress Job Tables controls this; the default value is *NONE and is recommended. If you have a need to compress the job tables, use the value of *NEXT. The Rochester Support Center has a couple knowledge base articles regarding job tables and job table compression that you may find helpful:
The permanent job structures are as the name implies — permanent and survive IPLs. These job structures are what allow ended jobs with output to remain on the system until the output is deleted or detached from the job. The permanent job structures consist of three main pieces:
- the spool control block
- the job message queue (for job log messages)
- the local data area
The temporary job structures are temporary, do not survive IPLs and are only associated with a job when it is active. There are many parts to the temporary job structures and they include such things as:
- the process control space
- the qtemp library for the job
- the job performance data space for performance data
- … and several other structures
The permanent and temporary job structures are created ahead of time and managed by the system. They are recycled for reuse; that is, once a job ends, the temporary job structures can be used by another job. Once the job has left the system (ended and no spooled files associated with it), the permanent job structures can be used by another job.
The Total Jobs (QTOTJOB) and Active Jobs (QACTJOB) system values define the initial values for the total permanent and temporary job structures. The Additional Total Jobs (QADLTOTJ) and Additional Active Jobs (QADLACTJ) system values define how many additional permanent and temporary job structures are created when necessary.
As I wrote last week, ended jobs with spooled output continue to use a job table entry and the permanent job structures for that job. Detaching spooled files can free up those structures for use by other jobs and reduce the number of jobs on the system.
Jobs can also have their job logs in an pending state (job log pending). I haven’t yet written about job log pending, but jobs with pending job logs also consume an entry in the job table entry and a permanent job structure. Good job log management can reduce the number of jobs on the system and I will write more in the future about job log management.
The redpaper “Best Practices for Managing IBM i Jobs and Output” has more information on this topic along with recommendations for setting the system values to control job structure management by the system, considerations for job table compression, more information on the job table warning PTFs, as well as suggestions for reducing the number of jobs on the system. This redpaper is one I consider a “must read” for all IBM i administrators.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.