Not sure about rules in multi-system environment, but with one system I believe it was possible to DIAGNOSE a catalog to be sure no serious problems existed, LOCK it, backup, redefine, restore/reorganize, UNLOCK while system was running and datasets in the catalog were OPEN and in use. As long as you could tolerate short-term inability to OPEN/CLOSE any datasets in the catalog, it was sometimes possible to move or rebuild a catalog with in-use datasets without disrupting critical loads - although admittedly this assumes you have enough control over or knowledge about the loads and datasets involved to make that assessment. One just had to be sure the batch jobs doing the work and TSO user controlling the process were designed to have no requirements for OPEN/CLOSE of datasets in the catalog
Of course there is always some risk - errors in the process or unrelated system failures in middle of process may end up requiring a viable standalone z/OS. But there is also a risk in continuing to use an obsolete feature whose usage is increasingly rare. Although IBM is committed to maintain compatibility, I would suspect they may not be able to test this support as thoroughly as some other system features precisely because it is obsolete and rare. In every new release or RSU level of z/OS there is the possibility IBM may unintentionally break IMBED/REPLICATE logic in some subtle way that because of its rare usage escapes initial detection during early testing. JC Ewing On 07/17/2013 11:00 AM, Skip Robinson wrote: > My shop is 24 hours every day of the year, leap or otherwise. We never > close. Mainframe here is key to the customer support system, which is > obligated to take and manage customer calls. Any day. Any time. > > A few user catalogs are required as long as systems are active. So taking > catalogs out of service means taking down all systems that share them. > That means total outage, since rolling applications among sysplex members > is precluded by loss of shared resources. > > Do we ever take all systems down? Sure, but that requires a business case > presented to the Global Change Advisory Board and approval from top > management. Here's my case: a few clunky old catalogs are causing me > embarrassment among my professional peers, who are taking snide shots at > me that make me feel like a high school schlub being dissed by the cool > kids. > > Maybe not. > . > . > JO.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > > > From: Ted MacNEIL <eamacn...@yahoo.ca> > To: IBM-MAIN@LISTSERV.UA.EDU, > Date: 07/17/2013 08:38 AM > Subject: Re: Old usercatalogs with IMBED and REPLICATE > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > Not all of us are, though. > If we wish to stay employed, we must follow their directives. > > - > Ted MacNEIL > eamacn...@yahoo.ca > Twitter: @TedMacNEIL > > -----Original Message----- > From: "R.S." <r.skoru...@bremultibank.com.pl> > Sender: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > Date: Wed, 17 Jul 2013 07:29:45 > To: <IBM-MAIN@LISTSERV.UA.EDU> > Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: Old usercatalogs with IMBED and REPLICATE > > W dniu 2013-07-16 21:19, Ted MacNEIL pisze: >> Preach all you want. >> It's management who sets priorities. >> > That's me. > -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN