True. At last the OP has MIM. And GRS to help. My LPARs are all single monoplexes, 4 of them. Not even GRS. PDSE sharing is pretty much only the SYSRES datasets that need to be. Tears ago, I got bit trying to share a vendor distributed PDSE parmlib. Decided then and there that I could live without PDSE features in most cases.
I'd like to do GRS, but lack the CPU resources > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Mark Jacobs > Sent: Wednesday, July 24, 2019 12:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sharing PDSEs in shared DASD Environment > > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs- > 40protonmail.com&d=DwIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8Ldrrv > xQb- > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=uAUpHjYU3mGwLx5ErYtDwQF- > 4Yd0E2So1uiOo1RJJDM&s=Z_ByYRZvSvYlMRpj12KIhN_rJF0jOwSLEvfqPx4PSh > s&e= > > ‐‐‐‐‐‐‐ 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
