×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 03 Jan 2013 14:21, Jeff Crosby wrote:
If a PWRDWNSYS *IMMED is issued in a CL program, does the CL program
stay on that statement until that job is bombed? Or does it start
the power down sequence and then move on?
If someone wants to test it today and let me know, that would be
swell. :)
This thread is already resolved, but I thought I would offer FWiW:
It is pretty safe to assume that a typical CL program will terminate
before the PWRDWNSYS can return control to the CLP. The history for and
the joblog from, the requesting job, will show that effect; i.e. the
requesting job will have failed abnormally according to the message sent
to QHST, and the last recorded request message in the joblog will be the
Power Down System CL command. The How to End (OPTION) parameter
specification of *IMMED ensures that "[o]ther than by handling the
SIGTERM signal, the programs running in those jobs are not allowed to
perform any cleanup." So...
Unless the CL program has an "invocation exit" [or equivalent, by
whatever name; e.g. registered activation group exit or a "signal
handling procedure for the asynchronous signal SIGTERM"] for which the
terminate instruction event is intercepted to allow some additional [but
limited; e.g. by various time limits, such as that specified on a
controlled power down request] amount of processing to perform some
/clean up/ activity before the call stack is collapsed. Note that the
effect is a new stack entry, and what was currently the top of the stack
[the requester of the /end/ feature] and all those programs below in the
stack, will end without continuing to their next instruction. Note that
irrespective of its naming, the special value *IMMED does not mean
"immediate" in every sense. While all jobs receive the /terminate/
event effectively immediately, any jobs with a handler still get some
amount of time to effect system-mandated cleanup plus some level of
user-defined cleanup activity being allowed, before the job stack
collapses entirely; as "controlled by the system values QENDJOBLMT and
QPWRDWNLMT."
Effectively the same issue for ending and for if cleanup is or is not
enabled, when the CLP is requesting instead the ENDSYS or ENDSBS *ALL.
That is, at least when not requested as a batch time limit [BCHTIMLMT]
request nor as a request from the interactive console job running in the
controlling subsystem; neither receives the terminate event. So the CLP
can be expected, similarly, to end before more CL requests can continue.
midrange.com
