RE: Multiple joblogs being created for some jobs

For the archives - Here is copy of previous CPS discussion with IBM development.

explanation of why you see only two CPI2417 messages and a bunch of joblogs. For the CPI2417 message, this is how it works:

When the job message queue fills up, we remove approximately 1MB of messages each time, and print the job log for the messages removed if the job message queue full action is set to *PRTWRAP. The 1MB is a fixed value, regardless of the size of the job message queue. The CPI2417 message is sent the first time we remove messages, and then each time the ENTIRE job message queue has been wrapped. For example, if the size of the job message queue is set to 64, the CPI2417 message is sent the first time messages are removed, then the 65th time, the 129th time, and so on. This explains why there are so many more printed job logs than the number of CPI2417 messages.

For the difference in why some joblogs are 150 pages and other times there are more, this is the explanation:

As for the size being different, the process queue space (which is the internal object type used for the joblog) can contain messages that appear in the joblog along with messages that will not appear in the joblog and just appear on program invocation queues for exception processing, etc. The size of the printed/wrapped joblog would only contain messages that can appear in the joblog so the size can differ depending on the number of both types of messages being removed/wrapped.

It was then asked if the messages that don't make it to the job log be covering some kind of a problem? And development responded with No, they wouldn't be covering a problem. The messages are either SLIC type messages or status messages because a message type of status is never put in the joblog. If a job is traced, the trace would contain an indication that a status message was sent and would show the messages that aren't making it to the joblog. If they think the joblog should not be wrapping, they could trace the job to see if there is are excessive status messages or even a lot of exception handling occurring. If an exception message was sent but then later handled and removed by an invocation that would take up space also until the wrap occurred.

As for seeing those messages on an invocation queue, this is the QUEUESPACE macro you and I used yesterday. But it sounds like tracing the job will show all messages as even the queuespace may not have all messages.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, August 18, 2014 8:50 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Multiple joblogs being created for some jobs

On 14-Aug-2014 13:10 -0500, Steinmetz, Paul wrote:

<<SNIP>>
Creation times for the joblogs are every 21 seconds.
There is no overlap.
The beginning and end time of each message does not match the creation
time of the QPJOBLOG.
Only the final 159 spoolfile matches.
The final joblog is 62 times larger (5,164 pages) then 2 thru 158
(81 pages)
<<SNIP joblog details; apparently from /final joblog/ per EOJ msg>>

What were the logged [and not filtered] messages in each of the spooled QPJOBLOG produced in response to [each of] the CPI2417 messages sent to the history log (QHST), would be of the most interest. What was in the final spooled joblog are not of much interest, with regard to finding the possible origin of the CPI2417.

If each of the 81-page joblogs are effectively identical, but only a couple CPI2417 were issued, then I would be suspicious that all of them were the result of the CPI2417; that there might be some defect whereby the CPI2417 is not properly being issued for every case.

If a job will be known to reproduce the condition of the multiple joblogs [including some for CPI2417], then as described in another reply, using servicing\debug can very easily assist to determine the origin for the [non joblog-server-produced] spooled QPJOBLOG files for a job; that includes probably identifying any that might be a result of the condition diagnosed by CPI2417, even if that message is [unexpectedly] not being sent.

--
Regards, Chuck
--
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.