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.
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
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