I believe the ENDSBS request initiates against each job in the
subsystem, an /effective/ ENDJOB request of equivalent inputs. That is,
if the OPTION(*CTRLD) DELAY(60) is issued to the subsystem, then as I
understand it, the same effective parameters are relayed to each job
immediately after the subsystem is marked ineligible to receive new
jobs; after changing to END status as the first direct result of the
ENDSBS request. I was under the impression that a job would get the
opportunity to reach its "if endsts=*controlled then exit_nicely" when
it was ended controlled while it was held. For example if a job was
running a program with a coded loop to do nothing more than "if
endsts=*ctrld then exit, else repeat" would exit normally when ended
*CTRLD while the job was held, because the end would first release the
job to get to its test for exit-on-terminate. However...
The ENDJOB documents that a currently held job which is being ended
with a DELAY() [only available with *CTRLD end] will not even have the
delay timer started until the job is released from the prior HLDJOB
request. That seems to imply that the ENDJOB would always effect an
immediate end for all jobs remaining held, where the immediate end is
initiated after the delay timer. That also would seem to contradict the
scenario earlier described [by Jim Horn] whereby a held process "seemed
to 'wake up' and processed data", continuing "just seconds after the
subsystem was ended controlled".
The HLDJOB documents that a held job "causes a job to be ineligible
for processing by the system", and that the job is held until [among
other reasons] ended by either of the End Job or End Subsystem commands.
I understood that the end-job-interrupt [like SIGTERM] would both
supersede the held status and implicitly release. I also expected that
was immediate with the ENDJOB, not only after the timer delay. Although
the status /held/ and status /end/ are mutually exclusive [the HLDJOB
doc does imply the request to end the job removes the hold], the ENDJOB
doc implies that only the signal handler processing is allowed if one is
even active, or only system cleanup is allowed when there is no signal
handler. I infer if that is the case, then the end of a held job
without a signal handler would /always/ have to end abnormal. There may
be something different about an end-subsystem request which would change
the outcome as compared to end-job request, but I doubt it. A couple of
simple tests [assume via job queue QBATCH into subsystem QBATCH enabled
with no competition or impacts] should provide a better answer by review
of the results:
sbmjob cmd(dlyjob 30) job(uniq1) jobq(qbatch) log(4 0 *nolist)
hldjob uniq1
endsbs qbatch option(*cntrld) delay(60)
wrkjob uniq1 /* normal or abnormal job completion? */
sbmjob cmd(dlyjob 30) job(uniq2) jobq(qbatch) log(4 0 *nolist)
hldjob uniq2
endjob uniq2 option(*cntrld) delay(60)
wrkjob uniq2 /* normal or abnormal job completion? */
Regards, Chuck
Pete Massiello wrote:
Does this mean if I did a Controlled shutdown with 60 seconds, does
it release the job as soon as the controlled shutdown is performed,
or does it release the job when the 60 seconds have expired.
Therefore, if I had held a job which was just shy of completing, and
it completes in less than the 60 seconds in the example, would it
then have a zero completion code?
CRPence wrote:
Actually AFaIK the controlled ENDSBS request instigates a
controlled end for each job. In the archive message
http://archive.midrange.com/midrange-l/200705/msg00943.html I
suggested that the conditions of HELD and END are mutually
exclusive, and therefore the controlled ENDJOB effects an implicit
RLSJOB [and presumably with no CPC1163 denoted action by a user
that could perhaps be identified as *SYSTEM or as I suggested then
by *ENDJOB]. Thus the /controlled/ end enables the jobs in the
subsystem to reach their coded test for "am I ending controlled"
rather than remaining held until they receive the /terminate
immediate/ instruction at the end of the timeout. <<SNIP>>
midrange.com
