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.
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>>
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.
This mailing list archive is Copyright 1997-2015 by MIDRANGE dot 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 here. If you have questions about this, please contact