Re: New job on V7.1

[CRPence <CRPbottle@xxxxxxxxx>]

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.