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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online