Take Advantage of the Job Log Server

IBM i expert Dawn May explains why you should change the default behavior of the server

This is a republished version of the blog Job Log Output, originally posted in 2011. 

Since starting my independent consulting practice, I have found most shops are not effectively using the job log server. The use of the job log server is controlled by the system value Job Log Output (QLOGOUTPUT) at the system level, and the LOGOUTPUT parameter at the job-level.  The default setting of the QLOGOUTPUT system value is *JOBEND, which means the generation of the spooled job log is done within the ending job.

While this default preserved compatibility with prior releases, it also means that most shops haven’t changed from the default behavior and are still not taking advantage of the job log server.

There are three options for the Job Log Output system value:

• *JOBEND—the job log is written to a spooled file when the job is ended.This is the default value and is compatible with prior releases and how job logs were generated.
• *JOBLOGSVR—when the job ends, the job log remains in a pending status until the job log is written to a spooled file by the job log server.
• *PND—the job log is not written to a spooled file but remains in a pending status.

While the shipped value for log output is *JOBEND, IBM recommends that you use the job log server (*JOBLOGSVR).  Using the job log server has a major advantage – the generation of the spooled job logs is handled in a more controlled manner. When hundreds or potentially thousands of jobs are writing job logs at the same time, you can generate significant drain on system resources—CPU and I/O – at once.  In addition, many jobs writing job logs at the same time can introduce contention on the QEZJOBLOG output queue.  By having the job log server generate the spooled job logs, the system controls the amount of work that is done at one point in time; if there are many job logs to be written, the job logs will remain in a pending state until the job log server can write the job log to the spooled file.

Controlling when job logs are created will improve system performance, but the related question to consider is whether you even need all those job logs written to spooled files. If you don’t actually need the spooled files, think about using the pending attribute, which I wrote about in the Job Log Pending post.  Job logs that are in pending status will never have their job log written to a spooled file unless you take explicit action to do so.  The system’s automatic cleanup function will remove pending job logs in the same manner as it removes spooled job logs.  

The most significant consideration for pending job logs is how you find the job log. If you need to display or print a pending job log, you can use one of the following methods:

• Use the Display Job Log (DSPJOBLOG) command and direct the output as required. 
• Use the WRKJOB or WRKUSRJOB command on ended jobs with pending job logs, similar to how you would work with an active job.  When the job log is pending, you use option 10 to display the job log, not option 4 to display spooled files.
• Use the Work with Job Logs (WRKJOBLOG) command, which has a parameter to display *PENDING job logs or *SPOOLED job logs.
• Use the Change Job (CHGJOB) command to change the Log Output value from *PND to *JOBEND. This will write the job log to a spooled file and move the job to output queue status.

I strongly encourage everyone to view the QLOGOUTPUT system value. If it is still at *JOBEND, consider changing it to *JOBLOGSVR and take advantage of the job log server.

---