Job Log Output

Last week I wrote about Job Log Pending. With job log pending, you do not have to write job logs to spooled files.

At the end of that blog, I mentioned how you can use the Log Output (QLOGOUTPUT) system value or job attribute to take advantage of job log pending. This week, I'll explain the values available for “Log output” and give some general recommendations.

There are three options for the 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. Using the job log server has a major advantage - the generation of the spooled job logs is handled in a more controlled manner. Remember the scenarios I described in last week's blog where you could potentially have hundreds or thousands of jobs writing job logs at the same time? That is a significant drain on system resources. 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 a lot of 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.

But do you really need all those job logs written to spooled files? If you don't, you should think about using the pending attribute. 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 removing pending job logs in the same manner as it removes spooled job logs. 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.
• Use the Work with Job Logs (WRKJOBLOG) command.
• 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.

 

Comments

[Rob Berendt]

We used this as soon as it became available. Prior to this a (now former) employee showed the users the command CLROUTQ QEZJOBLOG. This caused much wailing and gnashing of teeth trying to find stuff that went wrong.
The users no longer have to wade through joblogs in WRKSPLF and they don't delete much needed information.

[Aaron Bartell]

I'd be curious to know if anybody else out there in "Java on IBMi" land would be interested in having Java follow the same logging approach (i.e. use the joblog) so all logs can be found in the same assumed locations.

I get involved in running Java on a number of IBMi machines because of my open source project and it is always hard to get information about errors depending on where Java is putting them.

AaronBartell.com

[Franco Lombardo]

@Aaron
I'm an "Java on IBMi" guy too, and, yes, I'd like if Java would follow the same logging approach :-)

[Dawn May]

Hi Aaron,
I forwarded your comment about Java on i using the job log to the IBM i development team. While this would indeed be a nice enhancement, it's not something you will likely see happen. Since Java on i is the same implementation as on other platforms, it allows for the standard Java tooling in the industry to be used seamlessly on IBM i.

Dawn