Admin Alert: Changing the Limits on OS/400 Job Spool Files

June 23, 2004 Joe Hertvik

Recent versions of OS/400 let you set the number of spool files that a job can generate. While some administrators might view this feature as a blessing, others may think that it doesn’t do enough to stop runaway jobs. OS/400’s ability to limit a job’s spool files is an interesting but limited capability that is important to understand.

With V5R1 and higher versions of OS/400, IBM provides a global system value called Maximum Spool Files Per Job (QMAXSPLF), which controls how many spool files any OS/400 job can generate before it stops producing printouts and displays error message CPF4167: “Job cannot create any more spooled files.” On the green screen, you can find QMAXSPLF under OS/400’s Allocation (*ALC) system values by running the Work with System Values (WRKSYSVAL) command, as follows:

WRKSYSVAL SYSVAL(*ALC)

Or you can directly display and work with QMAXSPLF by running WRKSYSVAL this way:

WRKSYSVAL SYSVAL(QMAXSPLF)

To set QMAXSPLF in iSeries Operations Navigator V5R2M0, open the “configuration and service” node, then the “system values” and “jobs” nodes; then click the “printer output” tab. QMAXSPLF shows up as the “maximum printer output files (9999-999999)” field on the “printer output” dialogue in OpsNav.

Like most things, using QMAXSPLF has pluses and minuses. First, QMAXSPLF has an odd range of values that start with a minimum limit of 9,999 spool files for each job and increase that limit all the way up to 999,999 spool files per job. The default is 9,999 spool files per job, and for each job OS/400 counts spool files that are waiting to be printed as well as spool files that have already been printed. This means that because it takes a minimum of 10,000 spool files to hit a job’s spool file limit, QMAXSPLF has a limited use in preventing looping or runaway jobs from overrunning system storage with printouts.

But having an upper limit of 999,999 spool files per job can also help single-use workstations, such as distribution department terminals that can run for weeks printing shipping labels. In such a scenario, increasing QMAXSPLF can increase productivity by reducing the number of times a single-purpose terminal session needs to be restarted during the course of a year.

One big drawback with QMAXSPLF is that it is a global system value that applies to all jobs. Once QMAXSPLF is set, it is used for every single OS/400 job that produces printer output, with no exceptions. This means QMAXSPLF could be a boon for the shipping terminals described above, while also clogging the system with printouts that may never be sent to a printer from server jobs that are never shut down.

When you set or reset QMAXSPLF, the new value takes effect immediately. So when you increase the number of spool files that any job can produce in the system, you don’t have to restart running jobs. The new limit will be in force right away. However, if you decrease your system’s QMAXSPLF limit, OS/400 does not automatically delete spool files for jobs that already contain more than the new maximum number of spool files. So jobs that have already exceeded the new spool file limit should be able to keep all existing printer files, but they will not be able to create new spool files.

The thing to remember is that, once a job reaches the QMAXSPLF limit, there are only two ways to produce more printouts: you can end and restart the job, or create a new copy of that job. For jobs that produce excessive printouts, it’s worth understanding how QMAXSPLF works and how to take appropriate action to keep your production level jobs running.