[Default] On 24 Jul 2019 12:23:41 -0700, in bit.listserv.ibm-main [email protected] (Doug) wrote:
>You cannot share PDSE's across systems not in a Sysplex. Period. If you >want to share PDSE's, you have to have the systems in the same sysplex. >You do not need a JESPlex, but I believe you will need a GRSPlex to >accommodate the enqueues. If you share them, and particularly write to >one, you will need to refresh the incore data from the dataset. There >are procedures to do that. You may have to restore, but not always. I >went through this for a couple of months a couple of years ago, and >there was no other option. Make them non PDSE's if you need to share. >You may be able to get away with only reading from one, but even that is >dicey. Simple answer I got from IBM support: Don't do it. Given the number of shops that were sharing PDSs either within sysplex boundaries or between them, I am surprised that IBM seemed to neither find a way to allow at least limited PDSE sharing across boundaries nor provide mechanisms that would allow the shops that were doing sharing to meet those needs they believed were / are only satisfied by sharing. A system of master and mirror data sets with an appropriate mechanism for triggering and doing the updates probably could work for many shops. Clark Morris > >Doug > >Doug Fuerst >[email protected] > >------ Original Message ------ >From: "Clark Morris" <[email protected]> >To: [email protected] >Sent: 7/24/2019 3:12:33 PM >Subject: Re: Sharing PDSEs in shared DASD Environment > >>[Default] On 24 Jul 2019 08:24:17 -0700, in bit.listserv.ibm-main >>[email protected] (S B) wrote: >> >>>Thisis a simplified description of our environment (for thesake of this >>>discussion) >>> >>> >>>Weare running z/OS V2.3 and using CA MIM >>> >>>Wehave two LPARs LPAR1 Development and LPAR2 Production there two LPARs >>>areshared DASD but separate JES2 Spools and not SYSPlex. We >>>have"PDSESHARING(NORMAL)" in IGDSMS00 and clearly onlyhave SMSPDSE running. >>> >>>Somedevelopers have PDSEs for their .JCL datasets. We used to receive >>>requests to restore their datasets because their PDSE datasets were >>>corrupted. At that time and as part of the problem resolutions (and CA' >>>recommendation) we added the following entries to the MIM (CAMIMGR)and that >>>seemed to solve the issue (we did not get any more calls for >>>corrupteddatasets >> >>My complaints about PDSE are that it is even less safe to share PDSEs >>across sysplexes than it is to share PDSs and that PDSEs are not >>available at NIP, i.e. SYS1.NUCLEUS, SYS1.PARMLIB, SYS1.LPALIB, >>SYS1.LINKLIB and other IPL data sets must be PDS's and not PDSEs. The >>former problem may be taken care of enough by allowing sysplex sharing >>if that mechanism also can handle GDPS. The latter problem in my >>rarely humble opinion was the same customer surly short-sightedness >>that didn't allow SNA 327x devices to be consoles at NIP. The PDSE >>restriction bars a path to migrating to FBA just as the latter >>restriction required my employer to have 2 Bi-Sync local 327x >>controllers to avoid single points of IPL failure. >> >>Clark Morris >>> >>> SYSZIGW0GDIF=YES, >>> >>> SCOPE=SYSTEMS, >>> >>> EXEMPT=NO, >>> >>> ECMF=NO, >>> >>> RPTAFTER=30, >>> >>> RPTCYCLE=60 >>> >>>SYSZIGW1GDIF=YES, >>> >>> SCOPE=SYSTEMS, >>> >>> EXEMPT=NO, >>> >>> ECMF=NO, >>> >>> RPTAFTER=30, >>> >>> RPTCYCLE=60 >>> >>>Lookingback at this issue and in preparation for COBOL Enterprise upgrade >>>from V4.2, accordingto many writeups/red books that I could find, in effect >>>we cannot have PDSEs in ourenvironment this being one of them >>> >>> IBM PDSE DATA SET SHARING Basics >>> >>>I am assuming there areother shops like us - shared DASD but not SYSPlex >>>what are our options inusing PDSEs if any? >>> >>>Theseare our thoughts: >>> >>>SYSPlexingthese two LPARs takes away the separation of Development and >>>Production during systems upgrades and applications development (e.g., test >>>in development for two weeks before moving to production). Alsosharing the >>>JES2 Spool will be complicated >>> >>>Separatingthe DASD and master/user catalogs seems to be drastic change >>>technically andculturally >>> >>>Any feedbackand suggestions will be great >>> >>>Thanks >>> >>>Shahnaz >>> >>> >>> >>> >>> >>>---------------------------------------------------------------------- >>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to [email protected] with the message: INFO IBM-MAIN >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
