We don't share mastercats, because there was not yet really a reason for it and we have the updates well synchronized. The pro is of course that a mastercat problem will be isolated to a single system.
Besides that, you will always have a number of mastercatalogs, at least 3 per Sysplex, because you cannot share data with your 2 GDPS K-systems and more groups of 3 if you have more sysplexes that you must keep synchronized for most of the entries. Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Allan Staller > Sent: 26 September, 2018 16:10 > To: [email protected] > Subject: Re: Master cats as user cats on other systems - why? > > I tend to generally concur w/Brian, but I do want to add an observation. > > Any time there are (three of something) vs (one of something) you are > (almost certainly) guaranteed to the one or more of the three, out of > sync. > Correction of "out of sync" conditions is generally painful and involves > a great deal of research and time to correct. > > Or to say the above in the short and sweet manner: > Two or more of something that don't agree, is worse than having nothing. > > The above being said, most "out of sync" conditions can be prevented by > application of appropriate operational discipline. > It has been my experience that very few shops employ appropriate > operational discipline. > > For this reason, I lean towards shared, rather than separate. > > My $0.02 USD > > > > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Brian Westerman > Sent: Wednesday, September 26, 2018 1:01 AM > To: [email protected] > Subject: Re: Master cats as user cats on other systems - why? > > I think the op might really be trying to decide if it's "better" to have > a single MCAT for the site and thus have the same view of "everything" > or if having individual MCATs for each LPAR and then sharing them as > UCATs with the "other" LPARs is better. > > I have operated both ways and I really don't see a "super" benefit in > one method over the other that gives it something "more" than the other > way, I think that there are sites that have a philosophy of one MCAT for > the site and some that feel that each LPAR "needs" it's own MCAT. > > As for why they are shared, if you have multiple MCATs (one per LPAR) > and you want to be able to access data that is in MCAT-1 (on LPAR-1) > from a system that is using MCAT-2 (on LPAR-2) as it's MCAT, then you > need to make sure that MCAT-1 is available to LPAR-2 and since you can't > use STEPCAT and/or JOBCAT (any more) it's much simpler to define MCAT-1 > as a usercatalog of MCAT-2 (and MCAT-2 as a usercatalog of MCAT-1). > > I find that it's easy to get confused if you aren't careful in a > multiple MCAT system, and it's simple to overdo it with symbolics > whether you have a single MCAT or multiple MCATs, but that doesn't make > multiple MCAT's any less useful than a single MCAT, just different. > > With all of the things that IBM forces on us with z/OS, allowing you to > have a "choice" once it a while is (to me) a good thing. > > Brian > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ::DISCLAIMER:: > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > -------------------------------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > may contain viruses in transmission. The e mail and its contents (with > or without referred errors) shall therefore not attach any liability on > the originator or HCL or its affiliates. Views or opinions, if any, > presented in this email are solely those of the author and may not > necessarily reflect the views or opinions of HCL or its affiliates. Any > form of reproduction, dissemination, copying, disclosure, modification, > distribution and / or publication of this message without the prior > written consent of authorized representative of HCL is strictly > prohibited. If you have received this email in error please delete it > and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > -------------------------------------------------------------- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
