On Fri, 1 Jun 2007 07:29:25 +0200, Barbara Nitz <[EMAIL PROTECTED]> wrote:
-snip- >I beg to differ with regard to the INTIDS and UNKNIDS attribute, though. Given >that there is no way in hell to define it on a 1.6 system that runs mixed with a >1.8 system, it is wrong of console initialization code to 'ignore' an attribute (and >in fact use the absolute opposite -N instead of Y) that could not be defined >before. This is how CONSOLxx has always worked. If the console was previously defined in the sysplex, any values specified in CONSOLxx that do not correspond to the currently defined values are rejected with RC=3. This doesn't mean that you can't turn INTIDS on and have it persist. The way the CONSOLE control block sharing code works (by building in the assumption on the 'downlevel' systems that there are attributes that they don't know about but need to propagate) is that attributes set on the 1.8 system will be 'remembered' by the downlevel systems, even if the 1.8 system leaves the sysplex. So, if you want to have INTIDS or UNKNIDS set, you need to take two actions: 1) Put it in the CONSOLxx member. You can even put it in a member shared with 1.6/7. CONSOLE initialization will 'ignore' the new specifications on the downlevel systems without causing the console definition to be thrown out. 2) Either manually or via automation use the VARY CN command to 'activate' UNKNIDS and INTIDS on the consoles that you want it on. Obviously, the function will only work when the console is activated on a 1.8 system, but the attribute will stay with the console, even after all the 1.8 systems leave the sysplex (with one caveat, if you cold start the sysplex and don't IPL any 1.8 systems, you will have to re-establish UNKNIDS/INTIDS after 1.8 rejoins). >If you don't explicitly look out for that, and then take steps to correct the >console code assumptions during initialization, you will have a rude awakening >with regard to these two attributes. No 1.8 console will have it. And I don't >think any installation will go and rename their consoles (UCBs and all) when they >switch between pre-1.8 and 1.8 systems, just to get these attributes defined >for the first time. I don't believe that your understanding of how the code works is correct. If you set INTIDS/UNKNIDS, it will 'stick' to the console for the life of the sysplex, regardless of the presence/absence of a 1.8 system. >Effectively, the way it works now, you either have to cold-start a complete >sysplex to get the console attributes, or you have to go to lenghts to get the >attributes assigned as intended. (And as I said, I wonder what will happen to >those keywords when I re-IPL my 1.6 system that doesn't know about them.) Incorrect. See discussion above. > >Besides, once a 1.8 system is in the plex, the lower level systems don't have >the cond=m consoles anymore, just as you said. What I am missing here is a >message that announces that fact. A D C,MSTR just gives 'no consoles meet >speicifed criteria'. I just hope that we have all definitions in place so that won't >cause problems when we rollout 1.8 in mixed sysplexes. If you want to have consoles with MASTER authority, give them MASTER authority. VARY CN(..),AUTH=MASTER. It would be helpful to update CONSOLxx as well. The capability to have more than one console with MASTER authority has existed since MVS 4.1. > >Thanks for listening. >regards, Barbara No problem. Scott Fagen z/OS Core Technology Design IBM Poughkeepsie ---------------------------------------------------------------------- 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
