× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



In reviewing the IBM document "Planning For Controlled System Shutdown" I
learned something new.

Initially I thought the QUPSDLYTIM was completely ignored if you had
QUPSMSGQ set to something other that QSYSOPR.

Then I read that if 1) QUPSDLYTIM was set to *NOMAX and 2) the message
queue defined in QUPSMSGQ was _not_ being monitored, the system would go
into immediate shutdown. This led me to believe that my setting of
QUPSDLYTIM to 1200 seconds gave me the best of both worlds. The key was
whether or not that message queue was being monitored. As long as my power
handling program was active, it was in control and my setting of QUPSDLYTIM
to a numeric value caused the QUPSDLYTIM to be ignored. During restricted
state backup, since my power handling program was not active (meaning the
QUPSMSG was not being monitored) then QUPSDLYTIM would kick in and shut the
system down after 20 minutes, which is exactly what happened in this latest
outage.

Upon reading the remainder of the document, I think my revised
understanding was still wrong. I now think that setting QUPSDLYTIM to
anything other than *NOMAX will cause the system to shut down after that
time period EVEN IF MY POWER HANDLING PROGRAM WAS RUNNING. I've got to do
more reading. Assuming this latest understanding is correct (no bets) then
I've thought of a stopgap until I can completely figure things out: use a
*EXIT at the beginning of BRMS to CHGSYSVAL QUPSDLYTIM 1200, then use
another *EXIT at the end to CHGSYSVAL QUPSDLYTIM *NOMAX. Or, better yet,
do those CHGSYSVAL right in my power handling program.

I've found at least 3 versions of that IBM document so far, one from 2000,
one from 2002, and one from 2008. The one I've read cover to cover is the
oldest, naturally, so now I will compare with the other 2 versions and look
for differences.



On Tue, Dec 25, 2012 at 10:01 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 24 Dec 2012 07:34, Jeff Crosby wrote:
One question: Is there any way whatsoever that we can get a
complete, full, don't-miss-anything backup and still have that
UPS software running?

Activate a variation of the Power Handling program to the UPS Message
Queue as a Break Handling Program, within the console [or batch time
limit AKA batch restricted state] job running in the
[ending\restricted-state] controlling subsystem. The Break-Handling
Program [PGM() on CHGMSGQ] accepts three parameters, unlike the
Power-Handling Program. A break program in the same job as the save
activity will be activated by an event and the program will appear at
the top of the stack above whatever activity is currently in progress;
e.g. could pop [onto the stack] in the middle of the save of a library,
anywhere in a SAVLIB *NONSYS, in a SAV, etc.. See the "Note:" and its
activation and deactivation instructions from the doc snippet below:

IBM i 7.1 Information Center -> Systems management -> Backup and
recovery -> Controlling system shutdown using a power-handling program
-> Enabling a power-handling program to control system activity during a
power interruption
_i Writing a power-handling program i_

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzahr/rzahrwrtpgmco.htm
"You should activate the power-handling program at each initial program
load (IPL) and keep it active at all times. It should be accounted for
in the activity level available in work management subsystem
specifications.

The message queue that is specified in QUPSMSGQ is used for
uninterruptible power supply message processing. The program normally
allocates the queue by specifying the command:

ALCOBJ OBJ(xxx/yyy *MSGQ *EXCL)

When a message arrives,
...

Note: When the system has been placed in a restricted state (for
example, ENDSBS *ALL), your uninterruptible power supply handling
program will no longer be active. For this reason, it is necessary to
prepare an alternate method of dealing with your uninterruptible power
supply and any possible power interruptions that may occur while your
system is in a restricted state.

For example, when performing a save system (using the SAVSYS command) or
reclaim storage (using the RCLSTG command), your uninterruptible power
supply program will no longer be active after all subsystems have been
ended. Only a single workstation job is active. You can perform one of
the following actions as an alternative:

1. <<SNIP attended restricted-state activity>>

2. <<SNIP quick shutdown>>

3. Change your existing uninterruptible power supply handling
program for use as a BREAK HANDLING program which may be used while the
system is in a restricted state. This can be done by creating a second
version of your uninterruptible power supply program that does not
allocate the message queue specified in system value QUPSMSGQ. (In other
words, do not use the ALCOBJ command.) To utilize this program while in
a restricted state, before starting a dedicated function such as SAVSYS,
enter the command:

CHGMSGQ MSGQ(LIB/MSGQ) DLVRY(*BREAK)
PGM(LIB/PGM)

where (LIB/MSGQ) is the name the message queue specified in
system value QUPSMSGQ, and (LIB/PGM) is the name of your modified
uninterruptible power supply handling program. Now, should a power
failure occur, the power failure message is handled by the break
handling program, even while a function such as the SAVSYS command is
running. To deactivate the break-handling program, either have the user
sign off or enter the following command:

CHGMSGQ MSGQ(LIB/MSGQ) DLVRY(*HOLD)
PGM(*DSPMSG)

After you have deactivated the break-handling program, you should
immediately start your subsystems and your normal
uninterruptible-power-supply handling program.

..."

--
Regards, Chuck
--
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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.