"SIGNAL SHUTDOWN" is, I believe, a VM construct. It is not a machine construct.
>fully-architected hardware external interrupt (in the PoPs) >that indicates that the LPAR is being shut down. FWIW, there is no such external interrupt. There is a "service signal interrupt" and z/OS does receive some of those interrupts (not all). The particular events that are the "subject" of a service signal interrupt are not documented in the Principles of Operation. The functionality being alluded to is an event that asks the running entity (e.g., z/OS) to enter a wait state (presumably by doing some sort of quiesce operation) before a certain timeout limit has been exceeded. If it has not done so, then once that time limit has been reached the LPAR shut down goes forward anyway. It is my understanding that this timeout value is 5 minutes which might or might not be long enough for a reasonable z/OS orderly shut down. If true, then writing a message will not be enough. Non-software support would be needed to identify a longer timeout value (hence increasing the bill). Note also that it would be a bad thing to unconditionally force every LPAR shut down to wait an extra 5 minutes as there will be customers who do not care to set up monitoring for such a message. Having the customer inform z/OS of interest is another necessary, not difficult, part of the solution. >as long as an automation package or maybe even system rexx >could intercept the message and take action that was desired. I'm sure just about every site has a protocol for what it considers an orderly shutdown. z/OS itself has very little clue. When a customer wants an orderly shutdown, I presume that they initiate one. And if the "action that was desired" exceeds the time threshold, the deactivation will occur before it is "desired". This is perhaps a naive question but is the problem that the person who is getting rid of an LPAR does not talk to the person in charge of the system running on the LPAR (to me that's similar to holding the power-off button on your PC instead of doing a "shutdown") and just does the LPAR deactivation? I'll readily grant that it would be nicer if that communication did not need to occur, but I really find it a bit hard to believe that such communication is anything other than a necessity. I don't know if it will be felt that it is "nicer enough" to justify the cost. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
