A job log is invaluable in determining the cause of a problem when a job ends abnormally. If not properly managed, though, job logs can eat up huge amounts of system storage. Understanding how job logs get generated is the first step to understanding how to managing them.
Let's start at the beginning. What is a job log? Well, a quick search of IBM's iSeries Information Center says a job log is this:
A record of requests submitted to the system by a job, the messages related to the requests, and the actions performed by the system on the job. The job log is maintained by the system program.
[IMAGE]
[IMAGE][IMAGE]
Kenneth Graap
[IMAGE]
[IMAGE]
Every job that runs on your server has an associated job log that records its activities. A job log can contain the following:
- The commands in the job
- The commands in a control language (CL) program
- All messages associated with that job
What determines when a job log will be created?
There are several ways within OS/400 to specify the creation of or restrict the creation of a job log.
The message logging parameters on the job description and for an active job determine what kind of information will be collected:
I won't go into all the specifics related to those values at this time, but if the message logging 'TEXT' parameter is set to *NOLIST, a job log will be created only if the job ends abnormally. If the job completes normally, no job log will be created. This is the same whether the job is an interactive or batch job.
If any value other than *NOLIST is specified for the message logging 'TEXT' parameter in a batch job, a job log will always be produced -- whether the job ends normally or abnormally.
This works differently for interactive jobs, though. To conserve disk space consumed by job logs, the SIGNOFF command may be define...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
d as
So, by default, when an interactive job is ended normally, no job log will be produced as specified by the LOG(*NOLIST) parameter. However, if an interactive job ends abnormally, a job log will be produced.
This job log is usually stored in the QEZJOBLOG output queue in library QUSRSYS. You can determine where your job log output goes with this command:
Scroll down to the Spooling Description section of the Display File Description listing to see which output queue job log output will be directed to:
If you want to always force the creation of a job log from an interactive job, you can do it in one of two ways:
- When you sign off enter SIGNOFF LOG(*LIST) instead of using the default.
- Prior to signing off enter DSPJOBLOG OUTPUT(*PRINT).
When one of those options is used, a job log will always be created from an interactive job.
Now that you understand how job logs are created on the iSeries, let's look at how to view one?
To view a job log that has already been created, use one of the following commands:
To see ALL job log output on the system, use this command:
For further information on how to create/display or modify job descriptions, review the HELP text associated with the following OS/400 commands:
CHGJOBD
CRTJOBD
DSPJOBD
WRKJOBD
For further information on how to view/change a jobs message logging attributes and to display a job log, review the HELP text associated with these OS/400 commands:
DSPJOB
CHGJOB
DSPJOBLOG
---------------------------
About the author: Kenneth is a senior AS/400e system administrator at Northwest Natural Gas in Portland, Ore. He has extensive experience in all aspects of iSeries systems management. That includes proactive performance tuning, system software upgrades and maintenance, hardware upgrade planning, backup/recovery procedures and security.
==================================
MORE INFORMATION
==================================
- Suppressing job logs
"Kimk" says normally he wants his jobs logged. However, he has a few that create huge logs and he doesn't want them produced. He says, "I could do this as chgjob logging text to *nolist, but is that the easiest way?" Site expert Laird Scranton advises.
- Get QPJOBLOG routed to a different outq
"Mggraham" is trying to track a user problem in which the user didn't tell him of a problem until several days afterwards and by then the joblog outq had been cleared. How can he get the job log of a particular job routed to an outq that is different than the one specified on the QPJOBLOG file? A couple other users had some ideas.
- Determine when the last IPL was performed
How can you tell when the last IPL was performed? Site expert Rich Belles and a few other users share their methods.
- View a history log on the iSeries
A user asks, "We are working as quickly as possible to convert from s36 environment to native 400. Is there any way we can view a history log like what we had on our old s36?" Site expert Rich Belles describes what the iSeries can do.
