We also use log(4 00 *seclvl) logclpgm(*YES).
All joblogs go to one outq, QEZJOBLOG, which normally has between 200,000 and 300,000 joblogs.
We also save all outqs, including QEZJOBLOG, on a daily basis.
It is important to keep joblogs to admin a system, and also for PCI compliancy.
Even if a job runs normally, there are times when these joblogs are reviewed.

System cleanup job QSYSSCD auto purges QEZJOBLOG on a daily basis, based on the number of days set in Cleanup options.
Number of days to keep:
User messages . . . . . . . . . . . . . . . . . 14
System and workstation messages . . . . . . . . 40
Critical system messages . . . . . . . . . . . *KEEP
Job logs and other system output . . . . . . . 90
System journals and system logs . . . . . . . . 90

TAATOOLS has a command, SCNALLJLG, which we use as needed.

The higher number of joblogs on the system does slow down an IPL, or restore of a system, or migration.
But with the faster systems today, along with SSD, this time is now minimal.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Jones
Sent: Saturday, December 19, 2015 1:33 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.


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 is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

This thread ...


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

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