Re: jobs held in a subsystem when subsystem is ended

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