Yes, I have been following this discussion... First of all, Consoles does not keep any console information in the couple data sets. Secondly, the console attribute retention behavior has changed as a result of the Console Restructure.
Prior to the Console Restructure, when a console was activated for the first time, we fetched the attributes of the console either from PARMLIB or from OPERPARM depending on the type of console. If changes were made to any of the attributes of the console -- either while it was active or not -- those changes were retained and used whenever the console was reactivated -- as long as a simultaneously sysplex-wide IPL did not occur, in which case we fetched the attributes again from PARMLIB or OPERPARM. The reason this behavior occurred was because every system in the sysplex had a copy of all of the attributes for every console defined in the sysplex. Whenever an attribute was changed (by command), the change was propagated to every system in the sysplex. As long as there was one surviving system, it was able to pass the altered console attributes to any new system joining the sysplex. The only way to get Consoles to "forget" the altered console attributes was to make sure that -all- of the systems in the sysplex were dead before re-IPLing. Many customers were completely unaware of this behavior. One of the problems we were attempting to solve with the Console Restructure was the amount of console attribute information that we were constantly passing from one system to another (under serialization) to keep everybody in-synch. We had situations where a system joining the sysplex would request a copy of the console information and before it could be completely received, the information had changed and had to be fetched again. We had some cases where the system never got out of that loop and the update storm then propagated to other systems in the sysplex, hanging the entire sysplex. So as part of the Console Restructure, we made a concious decision to not have every system in the sysplex have a complete copy of all of the console information. (We had to back off of that somewhat due to some problems, but that was the intent). In z/OS R10, there is a new operations mode called SHARED mode that you can migrate to. In that mode, we only keep track of the attributes of active consoles. Once the console is deactivated, we forget its attributes, and when it is reactivated we refetch its attributes from PARMLIB or OPERPARM. All of the systems in the sysplex are still aware of all of the attributes of all of the consoles, but only the active ones. Also, we use a "lazy update" technique to propagate attribute changes from one system to another, but this is done using timestamp based serialization rather than the sysplex-wide ENQs that we used to use. In the past, the attributes had to be in-synch all around the sysplex because systems were making message routing decisions based on those attributes. We don't do that to the extent that we used to, so the lazy update is adequate. The primary reason we continue to propagate the attributes to all of the systems in the sysplex is so that DISPLAY CONSOLES will work. W. Kevin Kelley IBM POK Lab -- z/OS Core Technical Development ---------------------------------------------------------------------- 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
