_______________________________________________________________________________________
Note: This e-mail is subject to the disclaimer contained at the bottom of this message. _______________________________________________________________________________________ Hi all, It has always intrigued me whenever there is talk of new Master Catalogs, WLM datasets, Page Datasets etc. being used just to support a new operating system upgrade. My initial thought is always why ? The last time we built a new MCAT for an OP/SYS upgrade was about 7 years ago, for an upgrade of OS/390, don't remember the version, probably 2.4, but the only reason we did this was to move to new dataset naming conventions for Catalogs, IBM and third party software (away from the original conventions and IBM standard prefixes such as CEE and TCPIP etc. Since then we have used the same master catalogs, page dsns, WLM dsns etc. for every upgrade unless actually required to do so, which has been vary rare, and IIRC it was for Sysplex CDS's. When we upgrade to a new version of z/OS (which we now do annually), any new datasets are pre catalogued ahead of time (old ones are uncatalogued afterwards as part of the clean-up process). We have one Master Catalog per Sysplex or LPAR. We install software on our Sysprog Sysplex via serverpacs and then build the Sysres set of resvols (3 mod9's) using DF/DSS. And it's generally just an IPL to bring it in with a few occasional procedures to implement either just before, or just after the IPL. We have procedures to override Parmlib members etc. I am just curious as to why people still create new master catalogs etc when upgrading z/OS as it's hard enough without adding this extra complexity. This is also not meant as a criticism or belittling of anyone's procedures either. Just like to know. Oh, and to answer Alan's question, Assuming you have all the necessary co-req PTFS applied, you would use the existing WLM datasets, and then implement any changes after all members of the sysplex are at the same version. Any changes to WLM would need to be made on a lower level of z/OS I would think. >Date: Mon, 10 Jan 2011 07:57:31 -0600 >From: "Staller, Allan" ><[email protected]<mailto:[email protected]>> >Subject: Re: z/OS 1.11 upgrade - WLM couple datasets > ><snip> >We are in the process of upgrade z/OS 1.11 into a SYSPLEX. It is going to be a >rolling upgrade. I would like to know how other sites migrate the >LPARs to the new WLM couple data sets. Do they only upgrade to the new WLM >couple data sets when all the LPARs are upgraded? ></snip> > >I would just complete the Roll-thru and then re-install the policy. > >There is a note in the conversion guide about *possibly needing a larger set >of couple datasets due to a change in the record length. See >(GA22-74998-15. PP113 (BCP Migration actions - Reallocate the WLM Couple >dataset)). >From a quick perusal of this item it seems that if you do not have *a lot* >(FSVO "a lot") of workloads or report classes, you should be >unaffected. However, YMMV! > >Date: Mon, 10 Jan 2011 12:34:52 -0200 >From: ITURIEL DO NASCIMENTO NETO ><[email protected]<mailto:[email protected]>> >Subject: RES: z/OS 1.11 upgrade - WLM couple datasets > >.If you have all coexistence PTFs applied then there is no need to change your >WLM CDS datasets, just catalog them into your new MCAT. > >Ituriel do Nascimento Neto Thanks & Regards, Stephen Hall Mainframe Platform Manager INSURANCE AUSTRALIA GROUP (IAG) _______________________________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _______________________________________________________________________________________ ---------------------------------------------------------------------- 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
