|
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 forwrote:
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>
power
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
wouldwould 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
lighthave been enough to power the control panel/service processor/green
theon the front of the system and therefore would be supplying power to
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.
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
