Re: Trapping the LPAR Deactivate signal on z/OS?
On 7/7/2011 12:48 PM, Alan Altmark wrote: On Wed, 6 Jul 2011 08:39:51 -0400, Gary DiPillogdipi...@axiosproducts.com wrote: The challenge is that the code David refers to uses unpublished details of the SERVICE CALL instruction and the SERVICE SIGNAL external interrupt, so it seems unlikely that MVS will have a published interface for such applications. I don't think we need a published interface, we just need z/OS to issue some message that we can automate to start an emergency shutdown. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
Something like 'IOSE HMC REQUESTED SHUTDOWN IN PROGRESS' on the system console for automation to react to? On Fri, Jul 8, 2011 at 10:40 AM, Richard L Peurifoy r-peuri...@neo.tamu.edu wrote: On 7/7/2011 12:48 PM, Alan Altmark wrote: On Wed, 6 Jul 2011 08:39:51 -0400, Gary DiPillogdipi...@axiosproducts.com wrote: The challenge is that the code David refers to uses unpublished details of the SERVICE CALL instruction and the SERVICE SIGNAL external interrupt, so it seems unlikely that MVS will have a published interface for such applications. I don't think we need a published interface, we just need z/OS to issue some message that we can automate to start an emergency shutdown. -- Richard -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
On Wed, 6 Jul 2011 08:39:51 -0400, Gary DiPillo gdipi...@axiosproducts.com wrote: If you try to initiate BCPii in a z/VM guest you get the following message (z/OS V1R10): HWI010I BCPII DOES NOT OPERATE ON A VM GUEST. BCPII INITIALIZATION IS HALTED. BCPii uses machine interfaces that are not virtualized. The good news is that BCPii doesn't (directly) have anything to do with support for the LPAR deactivation (or SIGNAL SHUTDOWN, on z/VM) signal, though it would be a good way to let apps register to hear the signal (HwiEvent, perhaps). The challenge is that the code David refers to uses unpublished details of the SERVICE CALL instruction and the SERVICE SIGNAL external interrupt, so it seems unlikely that MVS will have a published interface for such applications. If z/OS is running as a z/VM guest, a companion CMS virtual machine could hear the signal and use the virtual line mode integrated console to start a shutdown job. When registered for the deactivation signal, there is a delay between the time the deactivation is requested and when it occurs. In an LPAR on a z10, the delay is 5 minutes. If the OS comes down sooner than that, the LPAR deactivates sooner. In a guest, the delay can be specified in the system configuration or directly the commands that generate the signal. And if you tell VM to SHUTDOWN, it will propagate the signal to the registered guests, and delay shutdown in order to give the guests a chance to shutdown themselves. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
At 12:47 -0500 on 07/07/2011, Alan Altmark wrote about Re: Trapping the LPAR Deactivate signal on z/OS?: When registered for the deactivation signal, there is a delay between the time the deactivation is requested and when it occurs. In an LPAR on a z10, the delay is 5 minutes. If the OS comes down sooner than that, the LPAR deactivates sooner. That is nice BUT there needs to be coordination between the LPAR and the Z/OS system running in it. The way you describe it, the LPAR tells Z/OS to shut down in 5 minutes or face what amounts to a UPS-Less power failure of the LPAR emulated CPU. What should be done is to support an interface where Z/OS acknowledges the Shut Down Order from the LPAR and have the LPAR wait for Z/OS to send a I'm Shut Down signal to the LPAR. There should not only be a 5 minute shutdown clock but a I'm pulling the rug out from under you clock that kicks in after the 5 minutes have expired and Z/OS is still shutting down and still has not completed. This way it gets one extension before the LPAR crashes it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
Yes it does need an SE. Not sure about the z/VM guest angle. snip Not having played with the BCPii, my understanding is that it can't be invoked by a (z/VM) guest, and needs a SE to talk to. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
Re: z/VM If you try to initiate BCPii in a z/VM guest you get the following message (z/OS V1R10): HWI010I BCPII DOES NOT OPERATE ON A VM GUEST. BCPII INITIALIZATION IS HALTED. Yes it does need an SE. Not sure about the z/VM guest angle. snip Not having played with the BCPii, my understanding is that it can't be invoked by a (z/VM) guest, and needs a SE to talk to. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
From the z/OS 1.11 annnouncement (209-242. Dated Aug 18, 2009). The sysplex failure management (SFM) component of XCF used in a Parallel Sysplex to manage failures and reconfiguration has been enhanced in z/OS V1.11. It is now designed to use new Base Control Program internal interface (BCPii) services to determine whether an unresponsive system has failed, expedite sysplex recovery by bypassing delay intervals when possible, and automatically reset failed systems without manual intervention. This new function is expected to allow SFM to avoid waiting for a period of time before assuming that systems have failed, improve the responsiveness of failure management, avoid operator intervention, and help limit or avoid sysplex-wide slowdowns that can result from single-system failures. Just to clarify, BCP/II is a mixture of HW/SW that allows communication with the HMC. I think the plumbing you need is already in place. Just needs to be accessed. HTH, snip I've been discussing the idea of whether it would be possible/useful to write something to trap the hardware LPAR deactivation signal and use that to trigger an controlled emergency shutdown of z/OS. On VM and VSE, there is a trap present in the base OS that grabs that signal and starts a controlled shutdown of the OS (you can simulate it using the SIGNAL SHUTDOWN command on VM). z/OS doesn't seem to have any knowledge of this and proceeds to die horribly when the timer specified on the deactivate fires and the hardware goes away. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
Not having played with the BCPii, my understanding is that it can't be invoked by a (z/VM) guest, and needs a SE to talk to. Dave, does the zPDT base code emulate a SE at all, let alone this functionality ? (I don't have one to play on). A question probably better directed at Bill over on the yahoo group I guess. Shane ... On Tue, 5 Jul 2011 08:07:38 -0500 Staller, Allan wrote: ... Just to clarify, BCP/II is a mixture of HW/SW that allows communication with the HMC. I think the plumbing you need is already in place. Just needs to be accessed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Trapping the LPAR Deactivate signal on z/OS?
I've been discussing the idea of whether it would be possible/useful to write something to trap the hardware LPAR deactivation signal and use that to trigger an controlled emergency shutdown of z/OS. On VM and VSE, there is a trap present in the base OS that grabs that signal and starts a controlled shutdown of the OS (you can simulate it using the SIGNAL SHUTDOWN command on VM). z/OS doesn't seem to have any knowledge of this and proceeds to die horribly when the timer specified on the deactivate fires and the hardware goes away. Seems to me that this would be a Good Thing to have even for a LPAR-only install (in case some operator deactivates the wrong LPAR, or some similar awfulness) -- z/OS could do what it could to save state and then go down as gracefully as the time allotted (the LPAR deactivate signal has an optional time delay parm) permits. (The original need for us was to trigger automatic shutdown of the System Z processing when the UPS battery was getting low on our zPDT development system). I have sample assembler code on VM to trap the signal, but am not sure how best to implement this on z/OS. Suggestions? Ideas? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Trapping the LPAR Deactivate signal on z/OS?
On Mon, 4 Jul 2011 07:09:31 -0500 David Boyes dbo...@sinenomine.net wrote: :I've been discussing the idea of whether it would be possible/useful to write something to trap the hardware LPAR deactivation signal and use that to trigger an controlled emergency shutdown of z/OS. On VM and VSE, there is a trap present in the base OS that grabs that signal and starts a controlled shutdown of the OS (you can simulate it using the SIGNAL SHUTDOWN command on VM). z/OS doesn't seem to have any knowledge of this and proceeds to die horribly when the timer specified on the deactivate fires and the hardware goes away. :Seems to me that this would be a Good Thing to have even for a LPAR-only install (in case some operator deactivates the wrong LPAR, or some similar awfulness) -- z/OS could do what it could to save state and then go down as gracefully as the time allotted (the LPAR deactivate signal has an optional time delay parm) permits. (The original need for us was to trigger automatic shutdown of the System Z processing when the UPS battery was getting low on our zPDT development system). :I have sample assembler code on VM to trap the signal, but am not sure how best to implement this on z/OS. Suggestions? Ideas? How does the hypervisor implement it? Via an EXTernal interrupt? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
