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

On 08 Nov 2012 09:41, Porterfield, Sean wrote:

From: CRPence

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 <<SNIPped: "... a
TCP/IP-related feature had issued the SBMJOB request.>>

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.

In the quoted but pared text, I had referred to both the submitting job and the submitted job. Perhaps that was confusing.

The message of interest with regard to my reference to a QTOC* named program, was for the submitting job, to obtain details\context for what specifically "had issued the SBMJOB request".

What the submitted job requested, the CALL, had already been shown. What had not been included about that job was the CPF1124 and CPI1125, which in a spooled joblog, appear before the request message that showed the CALL. Somewhat moot now, because the most telling detail had since, already been revealed; i.e the JOBQ used by the SBMJOB, as described by the first level text of the CPC1221, being QBATCH vs QSYSNOMAX. And it is pretty obvious even without seeing that joblog, that the system code had used JOB(*JOBD) JOBD(QDFTSVR), which for the lack of a better word, is asinine. Apparently the developers gave so little thought to the function, that they had not even come up with an explicit job name to identify the work :-(

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.

FWiW the context of the message CPC1221 from details provided by a spooled joblog including that message [a copy\paste of the first level text from an active joblog does not include those details], is what would be used to provide the conclusive proof. That spooled joblog would show which program [named with the prefix QTOC] had issued the [effective] SBMJOB request.

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).

If these delays still exist as recommendations from IBM for lack of IBM actually having provided proper resolution(s) for what is the origin for those daft suggestions, then I remain surprised that many and big customers still have not revolted. Coded waits are ridiculous, and should be considered unacceptable to most; i.e. why must one wait for several minutes, for something that may have completed in just a few seconds.? The only worthwhile and IMO acceptable resolutions would come from things like notification by an [effective] event, retrieval of or sending of a notified status enabling polling [e.g. "not done yet" messages on repeated requests, until "no longer active" message transpires], or most simply the ability to specify that the request should be performed synchronously for which any event or polling processing is performed by the command invocation itself instead of being deferred to the user code. I am shocked that after several releases, there have been no conversations [here] that I have seen, explaining that these coded waits are no longer necessary because there had since been provided by IBM, an appropriate means to learn exactly if\when the code can safely progress.