On 07 Nov 2012 15:25, Porterfield, Sean wrote:
A spooled joblog showing the "job submitted" message would
identify the program that did that;
The "CPC1221 Job 206319/BACKUP/QDFTSVR submitted to job queue QBATCH
in library QGPL." message is what I used to determine the sequence
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; i.e. information such as the program *from*
which the message was sent and the program *to* which the message was
sent would be included. If the completion message was sent *to* a
program named with the prefix QTOC, then one can safely conclude that a
TCP/IP-related feature had issued the SBMJOB request.
Presumably the "backup job" is a utility that issues the
ENDTCPSVR, as a defaulted action of that utility, perhaps limited
to what type of SAV activity was requested to be performed, or
perhaps instead as a user-configured\requested action, and then
that backup feature performs some SAVxxx activities.?
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 have no idea why a submitted job would be the implementation for
the ENTTCPSVR command to effect part of its work;
However at some point the OS established both the QSYSNOMAX Job
Queue and the QSYSWRK Subsystem Description
I would not be surprised that a response from IBM would suggest
that this specific WM path should not be inhibited; i.e. holding
the work within that path\routing is considered a usage issue.
However one might wonder it that were the intention, then why would
HLDJOBQ even be allowed against that JOBQ object name.?
I take that as a suggestion to open a PMR to get an official answer
possibly explaining why it was done this way and hopefully an
appropriate solution to prevent the jobs from sitting around daily.
Effectively. And FWiW, that the job was "submitted to job queue
QBATCH in library QGPL" instead of QSYSNOMAX suggests that [if performed
by a system program] is an even poorer implementation than I had
inferred. 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 delayed my reply for some rewording of the above, but I left it
mostly unchanged, having since seen a later reply that includes a
response from IBM. Shocking... Embarrassing. :-(