RE: Power Handling program?

Let's break this down into two parts:

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 queue.

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 your favorite.

--
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.