On Sat, 6 Dec 2008 15:56:15 -0500, Jim Mulder <[EMAIL PROTECTED]> wrote:
> MVS would not want a DG Machine Check for this situation. MVS's >response to a DG is to count it, and, under direction of the MODE >command, take a processor offline if the specified threshold is >exceeded. That kind of action would make no sense for a speed change >which affects all processors, and even less sense in an LPAR >environment where MVS is dealing with logical processors. I >suspect that LPAR might not even pass DG machine checks through >to its guests. Surely MVS should get the DG machine check for the cooling failure; not for the speed change, which is presumably already signaled by some newer mechanism. If the granularity is wrong for this - mapping to logical processors and such - then the answer is to fix that mapping and granularity. In the "good old days", there were all kinds of machine checks happening, due mostly of course to less reliable hardware. And there were model (and vendor) dependent routines to handle the details. These days it seems the service processor/HMC (or whatever the current term is) takes charge of all that stuff, phones home and notifies people via its own console (that no one is watching), rather than telling the operating system about the problem. It seems odd to me to go down the path of ill-tested SNMP or emails from the service processor, when there is a much more robust and *architected* mechanism already there. Sure, the guest OS can fail because of the hardware failure, but that'll get noticed PDQ! Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
