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



Jim,

Understood.

But why a remote q and not just q on the local LPAR?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Friday, April 10, 2015 11:01 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Power Handling program?

Paul:

You can accomplish this task many ways; the data queue example is one that tends to be more tolerant of OS changes which is why I like it, as I said it's an example. As Rob pointed out with newer hardware it might not even be needed in a completely virtualized environment, but Rob's set up is the exception not the rule. (After all Decko is a member of the LUG)

The message queue is the one defined in the QUPSMSGQ system value and the program attached to that message queue actually sends out the remote data queue entry. That program can, if needed, interrogate the messages and be smart about what to do etc. if you wish. Since it's a program it can do anything you want it to.

Once the remote data queue base set up is done, then you can expand the technique to many different needs based on the situation and imagination of the admin. Extending it is easy.

Is it the best way, maybe not. The only way, certainly not.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Friday, April 10, 2015 9:40 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Power Handling program?

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?

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.