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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to