Re: joblogs - how to reduce but not miss something important

Hi Tim,

From a developer's point of view, I'd prefer to see an approach closer to

Paul's below, because if something needs to be fixed, a developer is going
to be asked to make the change, and the job log detail makes that a lot
more efficient.

From an administrator's point of view, I can see wanting to reduce the

number of job logs, but only if the administrators are manually looking
through them for issues. Personally, I don't think anyone should be
manually looking for issues across a huge number of job logs. Consider
obtaining or building a tool to scan through all those job logs extracting
issues of concern.

I think that approach keeps everyone efficient.

Mike

from: PaulMmn <PaulMmn@xxxxxxxxxxxxx>

subject: Re: joblogs - how to reduce but not miss something important

While not actually a way to reduce the number of joblogs (we use
log(4 00 *seclvl) logclpgm(*YES) for almost all of our production
jobs), it helps if you don't dump -all- of your logs in one output
queue!

We have 6 output queues: JOBLOG1MO, JOBLOG2TU, JOBLOG3WE, etc. (one
queue for SAT + SUN). And a set of automated jobs to change the
print files for joblogs, program dumps, and display job to the daily
JOBLOG* output queue.

CHGPRTF QPJOBLOG OUTQ(JOBLOGxx)
CHGPRTF QPPGMDMP OUTQ(JOBLOGxx)
CHGPRTF QPDSPJOB OUTQ(JOBLOGxx)

This places all of the 'utility' output in one place. We save the
output queues as part of our daily backups, then clear the queues
after a few days. This makes the joblogs &c available to track
problems, but they are cleared out so they don't become more clutter.

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx