When we were first pitched COBOL V5 at SHARE, my immediate reaction was: What about shops that share load libraries outside a single sysplex? We were not one of those shops for historical reasons, but I had previous involvement with shops that used one large shared library for use by multiple LPARs. Traditional PDS libraries were always at risk, but PDSE--required by COBOL V5--were sitting ducks.
It is quite possible to create a migration tool that can transmit a load module to multiple PDSEs in multiple sysplexes, but until COBOL V5, there was little incentive to make this radical change. For me, a major impediment to COBOL V5 was not COBOL itself but creation of a whole new cross sysplex migration mechanism. That would affect folks beyond developers. The real kicker was that the migration tool would have to be created and implemented enterprise-wide *before* the first COBOL V5 was rolled out. Daunting. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Gibney, Dave Sent: Wednesday, July 24, 2019 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sharing PDSEs in shared DASD Environment The danger in sharing a PDSE "read-only" is when it get's updated "somehow" by "someone" by "mistake" > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of S B > Sent: Wednesday, July 24, 2019 12:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sharing PDSEs in shared DASD Environment > > > Thanks for all whoresponded and thank you for your suggestions – few > more points for clarification > > Each LPAR has its ownmaster catalog but user catalog are shared (we > use different Res Packs during thesystem maintenance). We also use SMS > and RACF (also shared) to separate development vs. productiondatasets > allocation and access. > > READ Only for PDSEsmust be working (or we are incredibly lucky) > because there are many IBM andother vendors PDSE load libraries that > are Read Only in our current environment. But we clearly cannotmake > an Application Load Library “ReadOnly” > > I originally thoughtusing RACF’ Conditional Access List (using > “WHEN(CRITERIA”and SMFID) to make “a PDSE Load Library” Read only in > one LPAR andUpdate in the other until I read this: > > “ThePDSESHARING NORMAL protocol provides a limited form of inter- > system sharing.Many systems may concurrently access a PDSE that is > OPEN for INPUT, or onesystem may access a PDSE that is OPEN for > OUTPUT. When a systemaccesses a PDSE that is OPEN for OUTPUT, that > PDSE cannot be accessed for INPUTby any other system. Conversely, if > any system accesses a PDSE that is OPEN forINPUT, that PDSE cannot be > accessed for OUTPUT by any other system”. So, we are in ahard spot > when it comes to using PDSE when we are upgrading the EnterpriseCOBOL > V4.2 which will be going out ofsupport the end of September 2021 – > right around the corner. I was just hoping for a hidden solution or > trick somewhere - wishful thinking I know. I wonder what the boss > would think about all these when he is back from vacation Thanks again > > Shahnaz > > > > > On Wednesday, July 24, 2019, 11:24:09 AM EDT, S B > <sb822...@yahoo.com> 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” > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
