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
