Kevin, thanks for following and for addressing my question. I have changed the title as the original thread has drifted to an POR or not POR discussion.
Thanks also for correcting my sloppy wording and guessing what I meant :-) I still think that at one point prior to console restructure console retention attributes were kept as part of the sysmcs xcf group (permanent status recording). I am 100% sure that it wasn't sufficient to 'only' have all systems down, in addition you had to re-ipl in a different order causing a re-initialization of the sysplex to do cleanup for console information (my apologies for again confusing a sysplex cold-start with a sysplex re-initialization). I have even looked up the thread where Bill Neimann confirmed this back in February 2004 (the discussion is in the ibm-main-archives archive): "Consoles members in the SYSMCS and SYSMCS2 groups do in fact request permanent status recording. However, Consoles has a protocol in which the first system to IPL into the sysplex deletes any members that are in the FAILED state, left over from a previous instance of the sysplex. So a sysplex-wide IPL in which the operator gives permission to reinitialize the sysplex (by responding 'I' to IXC405D - see the documentation of that message for an explanation of why the first system to IPL in has to be different from the last one that was taken down) does clean up residual Consoles members. " If the sysplex is not re-initialized, then the consoles attributes as saved by permanent status recording will be used. This was confirmed a bit earlier by Bill. The last system down in the sysplex still appears FAILED because there is no other system to mark it inactive left. If that last FAILED system is the first to IPL, it recognizes that this is an old sysplex instance and does not do re-initialization. And yes, I remember (and I debugged) a few syszmcs sysmcs#something ENQ deadlocks! So up until and including z/OS 1.9 this old behaviour still applies, right? The old attributes might have been used because they were still there and in a monoplex it is kind of hard to re-initialize short of formatting the sysplex CDS. After all, Dave did not say what z/OS he is on nor did he say what IEA196I messages (if any) he got. The fact that he could vary things to console makes me believe that he didn't hit the 99 defined consoles limit, though. If it wasn't defined as an inactive console, it could not get activated later. And the rest is speculation. Best regards, Barbara -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ---------------------------------------------------------------------- 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
