|
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.
Event driven languages can process this differently than procedural
languages. 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. 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. Programs that don't code for it
might pop up "invalid function key" or some such error. Maybe a 5250
environment variable about whether or not to pass %SHTDN to 5250 as an
indicator (or some such thing).
Either way, now let's look at it from a system task. You have 900
interactive programs and 35 batch programs running. Someone runs
PWRDWNSYS *CNTRLD DELAY(5). After 5 seconds it changes to *IMMED. Is
someone telling us that *CNTRLD will flush all cache? But what about all
those programs still running that won't end until it automatically changes
to *IMMED? Did it flush all cache first, and then end those programs? Is
that cool? Or, does it say, well, I know that someone requested *CNTRLD
but I had to switch to *IMMED but since they requested *CNTRLD I will
flush the cache after everything is ended? If you can find that written,
fine, show me. I still say, barring further proof, neither flushes cache
safely and you'd be better served by following the recommendations in the
hardware service manuals before replacing cache batteries, swapping out
disk drives, etc.
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: John McKee <jmmckee@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/16/2013 04:17 PM
Subject: Re: PWRDWNSYS
Sent by: midrange-l-bounces@xxxxxxxxxxxx
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 andstarting/stopping.
*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
cache
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
IOA for more .... When all jobs are complete, type pwrdwnsys *immed onan
OS/400 ...
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzame/rzamepci.htm
cache
PCI Card V5R3 - IBM
If you are installing 5580 or 5581, go to Type 5708, auxiliary-write
IOA for more .... When all jobs are complete, type pwrdwnsys *immed onan
OS/400 ...
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzame/eng47451.pdf
check
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
for system shutdown to shut down more gracefully, but I'm not sold thatit
does a magical job on cache.was
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
would have been coming from the UPS. Since nothing else on the UPS
listwouldpowered 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
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
