Peter Relson wrote: >"SIGNAL SHUTDOWN" is, I believe, a VM construct. It is not a machine >construct. <snip> >then writing a message will not be enough.
>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". I see your points, which is why I was thinking that a PVMSG approach might be better. An SVM could issue the PVMSG and wait for the z/OS guest to logoff, THEN do the SIGNAL SHUTDOWN. >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. I'm betting/guessing that there are more and more shops who want to be as lights-out as possible, especially wrt test systems running as z/VM guests. I can't speak for David's use case, but what I'd want is an enabling technology such as what I describe, not a full-featured (== high cost) solution. -- ...phsiii Phil Smith III [email protected]<mailto:[email protected]> Voltage Security, Inc. www.voltage.com<http://www.voltage.com/> (703) 476-4511 (home office) (703) 568-6662 (cell) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
