Leaving PDSESHARING(NORMAL) and using DISP=OLD (all the time) MIGHT work. Make sure you have PDSE_BUFFER_BEYOND_CLOSE(NO) in your IDGSMSxx members too.
Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, July 24, 2019 2:51 PM, Gibney, Dave <gib...@wsu.edu> wrote: > The only "moderately safe" way to share PDSE outside a sysplex is read-only, > from all LPARs after PDSE creation/population. > You can sometimes get away with it if you only update from 1 and only 1 LPAR. > But, the latency of the update being noticed by the others can cause issues. > Update from 2 or more LPARs and you will have corruption, > > > -----Original Message----- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of S B > > Sent: Wednesday, July 24, 2019 8:23 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Sharing PDSEs in shared DASD Environment > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
