IBM i Job Structures

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 Information 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 approximately 485,000 entries; 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. PTFs for 5.4 (SI29585) and 6.1 (SI30171) provide this support (no PTFs are needed for 7.1 as this support is part of the operating system). You create a data area named QMAXJOBPCT in QSYS to control the percentage at which you want the warning message to be sent. See the PTF cover letters or the redpaper referenced at the end of this blog for the detailed instructions.

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:

• Slow IPLs and Job Table Compression
• Job Table Capacity

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:

1. the spool control block
2. the job message queue (for job log messages)
3. 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:

1. the process control space
2. the qtemp library for the job
3. the job performance data space for performance data
4. … 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.

 

 

Comments

[Aaron Bartell]

After reading this I thought it would be nice to have a beginners tutorial of how WRKACTJOB compares to Windows Task Manager. In reality they don't compare very well because WRKACTJOB has MANY more capabilities and statistics, and that is EXACTLY what I think could draw people to the platform.

Obviously many existing IBM i people might night find it enlightening, but they could use it as a reference point when "selling" the virtues of IBM i to either new staff or justifying keeping the IBM i vs. switching to Windows.

[Kurt Thomas]

Interesting article, as always!

Compressing the job tables is the job tables version of what in a file system context would be defragmentation. IBM provides a way to defrag the file system while it is online (STRDSKRGZ); should there not be a way to defrag the job tables while there are online, in the background and with minimal performance impact on work performed by the system?

[Harry Tolzman]

Dawn:
This job structure article jogged my memory regarding a recent situation which I witnessed with a Series i customer. They have multi-threaded INTERACTIVE jobs running on their system. Can you sometime explain the concept of multi-threaded interactive jobs. I know and understand multi-threaded batch jobs but know nothing about multi-threaded interactive jobs. How are they created? What purpose do they serve? From a performance standpoint, does QPFRADJ adjust activity levels for multi-threads of interactive jobs?

Any additional info would be helpful. Thanks!

[Dawn]

Aaron - good suggestion.

Kurt - there has been discussion about being able to compress the job tables while the system is active, but it's not something that we have chosen to invest in; we've always had other changes that we deemed were more important.

Harry - I'll address your comment in a future blog article.

Dawn