|
Let's break this down into two parts:queue.
Part 1
<snip>
...When it receives the queue entry from the partition connected to
the UPS...
</snip>
Actually all partitions, IBM i and otherwise are connected to the UPS.
Part 2
<snip>
...(the program setup to watch QUPSMSGQ)...
</snip>
However, if you only have one lpar of IBM i who cares about QUPSMSGQ
that's another story. The others can be running fat dumb and happy
with a huge QUPSDLYTIM and rely upon this lpar to handle it all.
That's one way of doing things. I think I prefer each to handle QUPSMSGQ.
Why?
- multithreading. While one lpar is shutting down stuff, especially
if there are delays and stuff built in, the other lpars can be doing
their own shutdowns.
- redundancy. Let's say you have your lpar with QUPSMSGQ in it doing
some restricted state operation or undergoing maintenance at the time
of power outage (Murphy can be a real SOB). Granted, the odds of you
being snuggled in bed with visions of sugar plums dancing in your head
while you have an lpar down are a little low but as a fellow with
multiple lpars I have been known to go to a child's sporting event
while a less critical lpar was doing a full system save and rclstg.
That, and any lpar of VIOS and AIX is going to get that UPS signal anyway.
I do like Jim's idea of communicating to the HMC directly from IBM i.
But how do you put that delay in so you can get the lpar down and then
the HMC can shutdown the firmware?
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: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/10/2015 10:39 AM
Subject: RE: Power Handling program?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Jim,
Are you keying off of a specific message?
Why are you utilizing a remote data q?
Could you accomplish this with a WRKWCH?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Jim Oberholtzer
Sent: Friday, April 10, 2015 8:30 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Power Handling program?
That I am aware of no, I've not seen examples of that type.
However it's fairly easy to do. I like remote data queues. Set up a
remote
data queue on each partition. The program that listens for that data
queue entry would be able to perform an orderly shutdown. When it
receives the queue entry from the partition connected to the UPS (the
program setup to watch QUPSMSGQ), it does its thing. This program
would start with the start up program and I usually use QUSRNOMAX job
your favorite.
When you think about it this can be used for many types of
interpartition communications limited only by your need and
imagination. The program can be written in any language (I use CL) so use
--
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Thomas Garvey
Sent: Thursday, April 09, 2015 11:44 PM
To: Midrange Systems Technical Discussion
Subject: Power Handling program?
I've seen the suggested code IBM published for a Power Outage Handling
program when the message queue defined by the QUPSMSGQ system value is
allocated.
But what can be done when a UPS is supporting a server on which
multiple partitions are defined?
What is the connection actually made between the RS232 cable from the
UPS and the IBM i? It must be simply an IBM i port monitored by some
process in a single partition, right?
In this case, how would all the partitions be notified so they can be
shut down? And, if they could all be shut down, how would the server
itself be powered off, since PWRDWNSYS doesn't actually power the
server down (we do it through the HMC, which also manages another server).
Is there an IBM document describing this circumstance?
--
Best Regards,
Thomas Garvey
--
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.
--
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
