Re: PWRDWNSYS - job termination

On 17 Jan 2013 04:39, rob@xxxxxxxxx wrote:

John McKee on 01/16/2013 04:17 PM wrote:

I am reaching here. From a Unix class over twenty years ago,
shutdown of the system (that system did not have a handy-dandy
shutdown command) used two kill commands. The first was sent with
(I think) a value of 1, and processes could trap that code. They
could either just ignore it or do something. A short time later, a
kill with a 9 was sent. This killed the process as it could not be
caught or ignored. Maybe the *CNTRLD option does something like
this deep under the covers. Suppose system was not in restricted
state. A *CNTRLD shutdown >could< be used to allow processes
(subsystems) the opportunity to gracefully end. <<SNIP>>

There is function like that built into the system. And it was
recently discussed on this list. RPG can check for %SHTDN
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzasd/sc092508873.htm#bbshut
CL can check for RTVJOBA ENDSTS(&ENDSTS)

Those get activated when a *CNTRLD is done. Either via ENDJOB or
ENDSBS or even PWRDWNSYS. The problem is, let's say you have a data
queue program. You wait on the data queue for 30 seconds. If no
activity you check for %SHTDN. If no shutdown you go wait another 30
seconds. Now, someone runs PWRDWNSYS *CNTRLD DELAY(1). %SHTDN is
activated but you won't check it until the next loop. Before that
loop gets activated the *CNTRLD automatically gets changed to *IMMED
and your job goes down hard.

The RPG ShutDown test is intended only for controlled end, just like the CL End Status test.

Event driven languages can process this differently than procedural
languages.

Procedural does not preclude dealing with events. I alluded in the following message recently about the capability to deal with the event that terminates the process:
http://archive.midrange.com/midrange-l/201301/msg00499.html

You can try to submit a DCR or a COMMON requirement that %SHTDN hit
an interactive program waiting on a screen as if a function key was
pressed and you can check that indicator.

No need. That RPG feature does what it should and there are means to handle the termination too, in a different fashion.

Sounds simple and reasonable, and wouldn't necessarily be disruptive
on existing programs, but I question whether IBM would avoid it out
of hand as it has anything to do with updating the 5250 experience.

Of course both the controlled end and termination are just as valid for non-5250 programming.

The following might be worth reading to learn why and how of the handling of ending jobs:
http://www.mcpressonline.com/rpg/simon-s-solutions-monitor-for-end-job-operations-part-i.html
http://www.mcpressonline.com/rpg/simon-s-solutions-monitor-for-end-job-operations-part-ii.html