|
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
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.