Many of the larger IBM i environments need more sophisticated methods to manage the number of jobs on the system. If the absolute maximum number of jobs–as defined by the Maximum Number of Jobs (QMAXJOB) system value–for the system is reached, there can be some negative results such as:
- An unplanned outage due to hitting the maximum number of jobs
- A large numbers of jobs that contribute to long IPLs for unplanned outages.
- Consumption of job table entries
The main problem many customers have with reaching the maximum number of jobs is not with active jobs but with jobs that are in OUTQ status. In other words, the job ended but it still has at least one spooled file, perhaps only the job log.
A job on the system has control structures associated with it, even when the job has ended, if it has spooled files. These structures include an entry in the job table as well as the permanent job structures to store information about the job.
IBM has provided a system value Spooled File Action (QSPLFACN) and a job attribute (SPLFACN), which can help reduce the number of jobs on the system. The Spooled File Action values are either *KEEP (the default), to keep the spooled files associated with the job, or *DETACH, which allows the spooled files to be disassociated with the job. By detaching the spooled files, the job’s control structures can be freed for reuse by other jobs while the output remains available. Detaching spooled files can result in fewer jobs on the system, which is a good thing.
If you have jobs that have ended but have kept the spooled files, using the Change Job command (CHGJOB) with the SPLFACN(*DETACH) parameter will allow the spooled files to be detached and the job to go away.
Detaching the spooled files from the job may cause some operational differences since the spooled files can no longer be found using WRKJOB, CHGJOB, and so on. They can, however, be found using the WRKJOBLOG (for job logs) or WRKSPLF (using the JOB parameter) commands. All the normal spooled file commands like DLTSPLF work the same as they do on spooled files that are not detached.
One thing should be noted about the *DETACH support. While unlikely to happen, it is possible that if spooled files are allowed to exist on the system for long periods of time after the job ends, another spooled file might get generated which has the exact same spooled file name, job name, job user, job number and spooled file number. Many applications use only those parameters or just some of them to reference a particular spooled file. It would thus be possible for those applications to fail with an error for a duplicate spooled file (or duplicate job) message. All spool interfaces have added additional parameters for the job system name (the system where the job that created the spooled files ran) and create date and time so that the correct spooled file can be selected but older applications may need to be brought up-to-date to use them.
For more information about detaching spooled files and managing jobs on the IBM i, take a look at the redpaper Best Practices for Managing IBM i Jobs and Output.
A Simple Example:
In this example, I had a job that had two spooled files associated with it. The job log no longer existed because the system had automatically cleaned up old job logs. To free up the job structures, I detached the spooled files from the job. From the example, you can see that WRKJOB does not find the job after the spooled files are detached, but WRKSPLF will.
WRKJOB JOB(453851/DMMAY/QPADEV000D)
option 4 to work with spooled files:
CHGJOB JOB(453851/DMMAY/QPADEV000D) SPLFACN(*DETACH)
WRKJOB JOB(453851/DMMAY/QPADEV000D)
Job 453851/DMMAY/QPADEV000D not found.
WRKSPLF SELECT(*ALL) JOB(453851/DMMAY/QPADEV000D)
I’d like to thank Kevin Vette for his assistance in writing and reviewing this week’s article. Kevin works in the IBM i development lab on the print and spool team.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.