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.


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

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.


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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].