A: I've seen jobs on our system that seem to persist even though the job has ended and all spooled output has been either deleted or printed (all in a FIN status).
These jobs can be removed from the system. Do an ENDJOB on each job, changing the "How to end" to *IMMED, the "Delete spooled files" to *YES, and the "Maximum log entries" to 0, as shown in Figure 1:
Figure 1: Use ENDJOB to get finished jobs with no spool files off your system.
For most of these jobs, the SPLFILE(*YES) parameter is enough. But for stubborn jobs, OPTION(*IMMED) and LOGLMT(0) is sometimes necessary.
When these jobs are worked and you look at the spool files, you see the message "Job saved for possible reuse" at the bottom of the Work with Job Spooled Files screen. If you place the cursor on this message and press Help, you'll see the following:
"The job 212055/KS09615/QPRTJOB was previously used to spool output for user KS09615. The job will be removed from the system if it is not used in 24 to 36 hours. If you want to remove the job from the system immediately, use the ENDJOB command and specify SPLFILE(*YES) to end the job and delete its spooled files."
If you have TAATOOLS on your system, it's easy to find these jobs. First, run the command CVTWRKUSR (Cvt WRKUSRJOB to outfile) for user *ALL, status *OUTQ. Running this command will create file WRKUSRP, listing all jobs on the system that are finished. Buried in this file are the jobs you're interested in. Next, run the command CVTWRKSPLF (Cvt WRKSPLF to outfile) for user *ALL. Running this command will create file WRKSPLFP, which contains data on all the spool files on the system. Finally, create a query that joins WRKUSRP to WRKSPLFP. When you specify the type of join, select option 3: "Unmatched records with primary file." This query produces a list of jobs that have a status of *OUTQ but don't have any spool files.
It gets a little harder if you don't have TAATOOLS. You'll have to use the IBM commands WRKUSRJOB and WRKSPLF, and then print the output. Next, you'll need to copy each spool file into its own physical file and do a little programming to extract out just the job information from the two files. The exact method is a bit beyond the scope of this discussion, but if you need some help, drop me an email.
The question is, Why are these jobs saved? And the answer is . . . I don't know! I asked several IBMers who frequent the various online forums, and they didn't know. I asked a prominent ex-IBMer, and he didn't know!
I did find a reference to an object on the system called a "Work Control Block Table." In a discussion in a forum on MC Press Online, I found an editor's note that says, in part, ". . .As jobs are completed--i.e., no longer active, no spool files, etc.--the entry for that job in the WCBT is made available for reuse...."
The OS/400 Work Management V4R4 guide has this to say about the Work Control Block Table:
"When a new job enters the system, an entry must be available for the new job. If there are no entries available in the table for the new job, the table is extended. Your system will experience a performance degradation when job tables are extended. Too many available entries will lower your system performance during the IPL steps that process the table and during runtime functions that work with jobs. If the number of available entries is large, you can use the Change IPL Attributes (CHGIPLA) command to change the option to compress the jobs tables."
Figure 2 below shows the CHGIPLA command attributes. For the "compress job tables," my system was set to *NONE. I've changed it to *NORMAL, which means that the job tables will be compressed during a normal IPL.
Figure 2: Use the CHGIPLA command to ensure that the job tables are compressed during a normal IPL.
I think what we're seeing here, with respect to the finished jobs that are still on the system, are jobs whose entries in the WCBT (Work Control Block Table) have not yet been removed. (If you search MC Press Online for "WCBT," you'll find some interesting discussion). By changing the IPL attribute for "Compress job tables," I expect that there won't be any of these "finished" jobs on my system after our next IPL.
And that's as close as I can get. If any reader knows why these jobs remain on the system, please write in to the forums discussion associated with this article and let the rest of us know!
--Bruce Bardini
This email address is being protected from spambots. You need JavaScript enabled to view it.
Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. 
LATEST COMMENTS
MC Press Online