Take Control of your job logs:

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.
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.
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:
Message logging: LOG
Level . . . . . . . . . . . . 4
Severity . . . . . . . . . . . 00
Text . . . . . . . . . . . . . *NOLIST
Log CL program commands . . . . LOGCLPGM *NO
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 defined as
Sign Off (SIGNOFF)

Type choices, press Enter.

Job log . . . . . . . . . . . . LOG *NOLIST
Drop line . . . . . . . . . . . DROP *DEVD
End connection . . . . . . . . . ENDCNN *NO

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:
DSPFD FILE(QPJOBLOG)
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:
Spooling Description
Spooled output queue . . . . . . . . . . . : OUTQ QEZJOBLOG
Library . . . . . . . . . . . . . . . . . : QUSRSYS
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:
1. When you sign off enter SIGNOFF LOG(*LIST) instead of using the default.
2. 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:
DSPSPLF FILE(QPJOBLOG) JOB(job_number/Usrid/Job_name)

DSPJOB JOB(job_number/Usrid/Job_name) OPTION(*SPLF)
To see ALL job log output on the system, use this command:
WRKOUTQ OUTQ(QUSRSYS/QEZJOBLOG)
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