Best Practices for Managing Job Logs on IBM i

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.

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:

  
  http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/apis/qwtrm vjl.htm
  
  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.