RE: New job on V7.1

From: CRPence

e.g. the completion message sent to QTOCxxxx. The spooled joblog for
the submitted job would show details about the WM that
defined\started the batch job.

You lost me on the QTOCxxxx part.

A joblog spooled [with log(4 0 *seclvl)], in contrast to a copy\paste of just
the message identifier and first level text, will show some context for the message

The job was in a held jobq and had not run. The message showing the call was the only thing in the joblog. I moved one of the two jobs to another queue to let it run, and it was gone. I then changed the logging level on the other and moved it to run, and it went to joblog pending, so no spooled file still. I'm not sure if you meant the QDFTSVR job or the backup job for the QTOCxxxx part. A DSPJOBLOG on the QDFTSVR job is not very interesting. It shows that I moved it to another queue, shows the initial message I posted, then job ended.

We started years ago with a retrieval of the GO SAVE 21 program and
modified it for our purposes. In 2002, we added ENDTCPSVR, ENDHOSTSVR,
and ENDTCP per IBM recommendations. <<SNIP>>

Apparently the CPC1221 was logged following one of those requests?
If LOGCLPGM(*YES) is in effect, then where the message appears in the
joblog with respect to the Request messages being logged, also can be
used to help infer what\which request had issued the SBMJOB request.

I don't believe LOGCLPGM was *YES on the backup job, since I don't see the ENDTCPSVR line in the joblog. I do see the output from that command, showing each of the servers ending (or not, if they weren't running.) Going on the assumption that the messages are written to the joblog in the correct sequence, and processing is done for only one command at a time, it was definitely ENDTCPSVR *ALL that submitted the job.

Given the unfathomable stupidity of various circumventions for effecting
the successful ending of the TCP\IP that I have seen floated here on this
list [apparently recommendations from IBM], mostly IIRC two DLYJOB requests
for five or more minutes each, it is easy for me to expect that the submitted
job is just another daft attempt to deal with [uh, circumvent] what appears
to be a design problem :-(

I can't be sure how much is from what recommendation, but we have ENDTCPPPTP *ALL (which is now cruft, since we don't use PPTP anymore), followed immediately by ENDTCPSVR *ALL, ENDHOSTSVR *ALL, then DLYJOB DLY(60), ENDTCP, DLYJOB DLY(120).
--
Sean Porterfield


This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.