Re: Job on hold, ENDJOB *CNTRLD

Ending is a function of the process itself, so as a job status each of 'ending' and 'held' are mutually exclusive. The event for End supersedes the condition of Held, specifically so the end can break the job out of the hold.
As Paul alludes, the OPTION(*CNTRLD) suggests the job will be ended in a "controlled manner that lets the application program perform end-of-job processing" as documented in the help text. The only way to enable the application to perform its end-of-job processing is to have the end request _implicitly_ release the job. If the job is held, then the application would be unable to perform RTVJOBA ENDSTS() to test if the job is ending due to a 'controlled end' request.
One might argue that the implicit release should report a CPC1163 just as an explicit release does; perhaps the message replacement text for &4 could suggest *ENDJOB. That could be submitted as a design change request. Or maybe just as reasonable, to infer that the CPC1126 and CPC1125 sufficiently imply that the job is no longer held.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever.

M Lazarus wrote:

Paul,

The mystery to me here is that the ENDJOB *released* the held job in
order to cancel iteself. I would have expected it wait until manually
released. Or possibly to have waited until the timeout value is exceeded
and then released itself, effectively turning itself into an ENDJOB
*IMMED.

-mark

As far as I know, the main difference between ending a job *IMMED and
*CNTRLD is that the *CNTRLD gives the job a delay time so it can
close itself down. This assumes that the job is watching the system
feedback areas so it even knows it has been asked to shut itself
down. Once the time delay expires, *IMMED and *CNTRLD perform
exactly the same housekeeping-- closes files, puts things away,
wipes the counter clean, hangs up the dishrag, turns out the lights,
and locks the door.

--Paul E Musselman