Re: PWRDWNSYS

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. Not likely a big deal if already
running in restricted state. Neither option would appear to be viable
for flushing cache to disk. How would anybody know how long was long
enough to accomplish the disk writes? If a system had a lot of RAM
but relatively few users, couldn't the amount of deferred disk writing
increase somewhat?

My WAG.

John McKee

On Wed, Jan 16, 2013 at 2:57 PM, <rob@xxxxxxxxx> wrote:

<snip>
Wouldn't it be documented somewhere that the
PWRDWNSYS *CNTRLD performs differently
from PWRDWNSYS *IMMED from a disk cache perspective?
</snip>

That's the million dollar question. If I look at the help on PWRDWNSYS
you see nothing of the sort. You do see that
Note: When *IMMED is specified while the system is operating under
auxiliary power,
or if the delay time specified in the Controlled end delay time (DELAY)
parameter ends while the system is under auxiliary power...
To me that sounds like six of one, a half dozen of another. Same thing.

Numerous types of powering down the system are discussed at
http://www-01.ibm.com/support/docview.wss?uid=nas161209687dac0128386256d630055b0b0
and only those performed by control panel functions are flagged as cache
hazardous.

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/p7ed5/ared5exusesasfab.htm
just mentions pwrdwnsys and makes no differentiation between *CNTRLD and
*IMMED. PDF version available at
http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/topic/ared5/ared5.pdf

In a hardware manual available at
http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/topic/arect/arect.pdf
says use *IMMED in talking about very general terms in starting/stopping.

And more searching at ibm.com for pwrdwnsys cache look like

PCI card
If you are installing 5580 or 5581, go to Type 5708, auxiliary-write cache
IOA for more .... When all jobs are complete, type pwrdwnsys *immed on an
OS/400 ...
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzame/rzamepci.htm


PCI Card V5R3 - IBM
If you are installing 5580 or 5581, go to Type 5708, auxiliary-write cache
IOA for more .... When all jobs are complete, type pwrdwnsys *immed on an
OS/400 ...
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzame/eng47451.pdf


So I'd love to see some IBM documentation that a *CNTRLD is better for
cache. Oh, sure, I strongly recommend bringing the system down to a
restricted state by first shutting down applications you know you have
controlled ways, like:
- ENDDOMSVR of domino servers
- Changing data queues for never ending programs which are written to
check them.
- Sending break messages to users imploring them to finish up and sign
off.
And then after that running
ENDSBS SBS(*ALL) DELAY(300)
and after you receive the message the system ended to restricted state
PWRDWNSYS *CNTRLD DELAY(120)
SIGNOFF *LIST
I do agree that *CNTRLD does allow applications that are written to check
for system shutdown to shut down more gracefully, but I'm not sold that it
does a magical job on cache.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Gqcy <gmufasa01@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 01/16/2013 03:11 PM
Subject: Re: PWRDWNSYS
Sent by: midrange-l-bounces@xxxxxxxxxxxx



currently, the batteries on my system have day counters.
count the number of days up.
count the ADJUSTED number of days up (I see it has a heat check).
count down the number of days to warning.
count down the number of days to error.

Does the system also have checks to see how the batteries ACTUALLY
are performing?

...
Wouldn't it be documented somewhere that the
PWRDWNSYS *CNTRLD performs differently
from PWRDWNSYS *IMMED from a disk cache perspective?









On 1/16/2013 1:22 PM, Evan Harris wrote:

My understanding is that the batteries are there to cater for
precisely this situation.

They (the cache batteries) aren't powered externally; they ensure the
cache guaranteed power and is therefore protected in the case of an
unexpected power loss.

That's why when the cache batteries fail, your performance is degraded
- the system doesn't use the cache as it is no longer guaranteed
protected.

On Thu, Jan 17, 2013 at 7:52 AM, Jeff Crosby<jlcrosby@xxxxxxxxxxxxxxxx>

wrote:

Would the cache batteries have held properly from whenever the UPS
batteries went dead until 1pm?

When unstable utility power was restored at 1pm (9 hours), then some

power

would have been coming from the UPS. Since nothing else on the UPS was
powered on, I assume whatever little power was available from the UPS

would

have been enough to power the control panel/service processor/green

light

on the front of the system and therefore would be supplying power to

the

cache batteries.

Does what I just wrote make sense?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.