Re: New job on V7.1 -- MIDRANGE-L

On 07 Nov 2012 15:25, Porterfield, Sean wrote:

From: CRPence

<<SNIP>>

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
of events.

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. :-(