Re: Any way to avoid QPJOBLOG?

[PaulMmn <PaulMmn@xxxxxxxxxxxxx>]

Siva--

A joblog is created for every job in the system.  The logging level 
controls how much of the information is kept once the job ends.

LOG(4 00 *SECLVL) LOGCLPGM(*YES)        This keeps everything, all the time.

LOG(4 00 *NOLIST) LOGCLPGM(*YES)	This only keeps a joblog if 
the job ends abnormally.

For many of our jobs we use the *NOLIST option-- we only need to see 
the joblog if there's a problem.  In that case, we don't care about 
the size of the joblog because we want to find out what went wrong.

To help administer our joblogs we've created 6 output queues: 
JOBLOGMO, JOBLOGTU, JOBLOGWE, JOBLOGTH, JOBLOGFR, JOBLOGSS.  We also 
run a job every day that points most the system-generated reports to 
these queues.  The output queue of the day is passed as parameter 
&OUTQ:

             PGM &OUTQ

             DCL &OUTQ *CHAR 10

             CHGJOBD QPWFSERVER OUTQ(&OUTQ)

             CHGPRTF QPDSPMSG OUTQ(&OUTQ)

JOBLOG:
            CHGPRTF    FILE(QPJOBLOG) OUTQ(&OUTQ)
              MONMSG     MSGID(CPF0000) EXEC(DO)
                DLYJOB     DLY(30)
                GOTO       CMDLBL(JOBLOG)
              ENDDO

PGMDMP:
            CHGPRTF    FILE(QPPGMDMP) OUTQ(&OUTQ)
              MONMSG     MSGID(CPF0000) EXEC(DO)
                DLYJOB     DLY(30)
                GOTO       CMDLBL(PGMDMP)
              ENDDO

DSPJOB:
            CHGPRTF    FILE(QPDSPJOB) OUTQ(&OUTQ)
              MONMSG     MSGID(CPF0000) EXEC(DO)
                DLYJOB     DLY(30)
                GOTO       CMDLBL(DSPJOB)
              ENDDO

             ENDPGM

The reason that 3 of the changes monitor messages and loop back to 
retry is because some of them might be actively in use when the job 
runs (usually just before midnight).

This separates the joblogs so we only have a single day's logs in 
each output queue.  We have a program that comes with our job 
scheduler that 'ages' output queues so that the joblogs disappear 
after 2 weeks-- so we don't end up with too many.

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx