The overwhelming majority are status messages from 3rd party apps that are beyond my control. I minimize my parts to a practical level, but that's just optimizing a tiny slice of the overall pie.
Thanks
-----Original Message-----
From: Rob Berendt [mailto:rob@xxxxxxxxx]
Sent: Monday, May 04, 2020 2:15 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Job Log Explorer from cilasoft
One might discuss why the joblog is so full in the first place.
I had one developer who wanted the job log message size increased so that his job would not abort. Or changed from *NOWRAP. It was discovered it was in an infinite loop and no amount of size would have help. He had plenty there to figure out the infinite loop. He resolved the correct problem. In this case more joblog would have just made it more difficult to find the original problem.
Sometimes a joblog records too much stuff. For example, one does a DLTF with a MONMSG in case it didn't exist. But they left the joblog clutter there instead of putting some action on the MONMSG to remove the clutter. Not only is there too much woods to see the trees but you may be focusing on the wrong problem, like why did this DLTF fail? Or, you try to search for only exception messages and you have thousands of these DLTF exceptions. Of which you could not possibly care less.
Perhaps the joblog severity is too low and logging everything.
Perhaps you are using a DSPPGMMSG when it may be more effective to log to a file. Either a stream file in /tmp or a DB2 file. I know it can be frustrating to have to look elsewhere than a "joblog" to find a log. I do. I get it. I feel that pain when running a bunch of qsHell stuff. But it's something one eventually has to get used to. People coming from other platforms probably find looking in a spool file a bizarre concept.
See these parameters to CHGJOBD:
JOBMSGQFL
JOBMSGQMX
LOG (especially the severity part)
LOGOUTPUT
But you may have a point. On a full joblog you have three options:
1 - Abort the job
2 - Wrap over the job log.
3 - Spool some of the job log out and go on.
You could still use the API on the unspooled joblog and handle the rare exceptions otherwise.
There is another option. Read the help on LOGOUTPUT on the CHGJOBD command. There is an API you can use to direct the joblog to a database file.
Job log output (LOGOUTPUT) - Help
Specifies how the job log will be produced when the job completes.
This does not affect job logs produced when the message queue is
full and the job message queue full action specifies *PRTWRAP.
Messages in the job message queue are written to a spooled file, from which the job log can be printed, unless the Control Job Log
Output (QMHCTLJL) API was used in the job to specify that the
messages in the job log are to be written to a database file.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
midrange.com
