Re: ENDSBS *ALL in a batch job

On 8/13/2013 3:36 PM, rob@xxxxxxxxx wrote:

Help me with this thought process...

First, when QUPSDLYTIM kicks in, does it do
- PWRDWNSYS *CNTRLD DELAY(...), which, after the delay kicks in, converts
to *IMMED.
- PWRDWNSYS *IMMED
- some unique process?

I suspect that it goes into a PWRDWNSYS *DELAY because changing
QUPSDLYTIM doesn't alter the power down time as measured by the clock on
the wall.

I am thinking that if I have a job stuck that requires ENDJOBABN to kill
it that the following: ENDSBS, ENDSYS, PWRDWNSYS are all held up until
that job is killed with ENDJOBABN.

Ah, the light comes on. You didn't have a rogue job earlier in the week
that you issued ENDJOBABN on. You have a rogue job that you haven't
discovered yet, the thunderstorm cut utility power and you're on UPS and
the UPS power handling program is trying to gracefully bring the machine
down.

Since my previous ENDSBS *ALL *CNTRLD DELAY(120) has already went past
it's DELAY(120) and converted itself to *IMMED and still didn't die; that
I've already killed everything that's going to go down 'normally'. All
that should be left is:
- The controlling subsystem with no jobs but the UPS job.
- The subsystem containing the job needing ENDJOBABN. With the only job
in that subsystem being that job needing ENDJOBABN.
- The actual job needing ENDJOBABN.
Since running ENDJOBABN automatically flags your next IPL as abnormal why
should I take the effort to list out all jobs, and run ENDJOBABN on any
non subsystem job left? Again, all that should be left are one or two
subsystem jobs and the job needing ENDJOBABN. That job is going to go
down hard either way.

This seems reasonable to me.

However, if there isn't some unique process down by QUPSDLYTIM, and it
requires some iteration of PWRDWNSYS to run (internal or otherwise) then a
hard slam may not flush cache? Or does PWRDWNSYS not really flush cache
anyway?

The last PWRDWNSYS I did on an emergency (utility power) basis happened
on a system where the utility power was out all over the building.
Hundreds of sessions dropped simultaneously as the PCs all went down
hard. Did a PWRDWNSYS *IMMED because the UPS batteries were old
(scheduled to be replaced in 2 weeks). Machine did not report damaged
objects when the machine restarted although the database was a little
incoherent from so many interrupted interactive jobs. But that wasn't
an OS problem, it was my application's problem.

In that case then perhaps I should do the job listing thing.

Most of the LPARs you have are big enough to run that API very quickly,
maybe adding 5 seconds to your orderly shutdown process. I'm probably
going to review my UPS handler to add it thanks to you sharing your
thoughts.

--buck