Many environments keep spooled job logs for some period of time for diagnostic purposes. However, keeping job logs, whether as spooled files or in a pending state, consumes a permanent job structure for each job. On some of the largest IBM i installations, these job logs are the major reason for large numbers of jobs on the system. The actual number of active jobs is relatively small compared to the total number of jobs on the system.
At this time, IBM does not increase the number of jobs on the system. Detaching spooled files is one method you can use to manage large numbers of spooled files.
In this technote, we provide some best practices on managing job logs.
Dawn May, Angela Newton, Mike Russell, Dan Tarara, and Kevin Vette
IBM Rochester Development Team
For our discussion, we focus on why are job logs kept and whether you can use a more granular control.
First, you can set up a job’s logging level to get all messages logged to the job log, but the job log is produced only if the job ends abnormally. If the job ends normally, no job log is generated, using the LOG(4 0 *NOLIST) setting.
When ending jobs, you can indicate that you do not want a job log, as shown in the following table.
|Command||Parameter for no job log|
|End Job (ENDJOB)||LOGLMT(0)|
|End Prestart Jobs (ENDPJ)||LOGLMT(0)|
|End Group Job (ENDGRPJOB)||LOG(*NOLIST)|
|End Subsystem (ENDSBS)||ENDSBSOPT(*NOJOBLOG)|
|End System (ENDSYS)||ENDSBSOPT(*NOJOBLOG)|
|Power Down System (PWRDWNSYS)||ENDSBSOPT(*NOJOBLOG)|
|Clear Job Queue (CLRJOBQ)||LOG(*NONE)|
|Sign Off (SIGNOFF)||LOG(*NOLIST)|
Consider the following system values with associated job attributes for job log characteristics:
- QJOBMSGQFL: Job message queue full action
This system value determines the behavior when the job message queue is full.
*NOWRAP ends the job when the job message queue is full. Use this value to prevent short running jobs from looping endlessly in error situations.
*WRAP allows new messages to overlay old messages when the job message queue is full. Use this value for long running jobs.
*PRTWRAP creates a spooled file for the job log prior to wrapping to allow new messages to overlay old messages.
- QJOBMSGQMX: Maximum size of job message queue
This system value sets the size of a job’s message queue. The shipped value is 16 MB, which for many jobs might be too high. Setting this system value to a high number can over commit a system’s storage. For example, if you have 20 000 active jobs and set QJOBMSGQMX to 64, the system can (in the worst case) use 1 280 000 megabytes for job message queues. Even systems that are large enough to run a lot of active jobs probably do not have that much unused DASD. When jobs hit a common error loop, even if it is only 5% of the active jobs, you can start losing storage quickly. Two points:
You need to set limits using the system value and the job description values.
The system uses storage to run. It uses a lot more storage to handle errors, and you need a fairly wide margin to avoid running out of storage.
Setting QJOBMSGQMX to 8 and QJOBMSGQFL set to *WRAP is a good, general configuration. If you have a specific need for a larger job log, set these values with care and with knowledge about the jobs that specifically need that high of a job log for special problem cases. Setting the QJOBMSGQMX system value to 8 limits the number of job log messages for a job. It can also reduce the recovery time for IPL after some system failures.
- QLOGOUTPUT: Job log output
This system value allows you to control if, and when, spooled job logs are created.
*JOBEND specifies that job logs are spooled when the job ends. Only use *JOBEND if you have a dependency on the job log being available immediately after the job ends. When many jobs end at the same time, using *JOBEND can result in a CPU spike as well as potential contention on the output queue.
*JOBLOGSVR specifies that job logs are spooled by the Job Log Servers some time after the job ends. Using *JOBLOGSVR is fairly close to using *JOBEND and tends to operate more smoothly (with less contention and less CPU spike).
You might want to shut down the job log servers to a restricted state before ending the jobs, depending on how much sequencing you do when ending work. Ending the job log servers prior to going into restricted state prevents the writing of job logs for jobs that are being ended (assuming those jobs use *JOBLOGSVR). IBM generally recommends using *JOBLOGSVR.
*PND keeps the job logs in a pending state until they are spooled or deleted from the system. Pending job logs reduce CPU and contention. Pending job logs, however, consume a job structure, even if you are detaching spooled files. The job descriptions for several server jobs are configured to use LOGOUTPUT(*PND), helping to avoid CPU spikes and contention when large number of server jobs end at the same time. The automatic cleanup function (GO CLEANUP) deletes pending job logs in the same manner as spooled job logs; however, if you are not using the system’s cleanup feature, then you must do your own cleanup. Cleanup is not optional, because if cleanup is not done, the system can run out of job structures or can fill with spooled files. To clean up pending job logs, use the QWTRMVJL API:
Specify a zero value for the “days since job completion” parameter to clean up the job logs immediately. Finally, if you are using the QMHCTLJL API, do not use pending job logs. Using the control job log output API makes sense only if you are creating the job log when the job ends.
V5R4 introduced the WRKJOBLOG command. You can delete job logs from this interface. In V6R1, you have the option to delete all job logs.
- QJOBMSGQSZ: Job message queue initial size
This system value is obsolete and no longer used.
- QJOBMSGQTL: Job message queue maximum initial size.
This system value is obsolete and no longer used.
For a more detailed discussion about this topic, refer to Best Practices for Managing IBM i Jobs and Output (and a few other special tips), REDP-4454.
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.