You can have a base sysplex and you don't need to share JES spool. I'm going to guess you have different master catalogs for each lpar and you can still keep different master catalogs. Now with a base sysplex you could have a shared SMS and HSM environment if you want, but you don't have to do that. You can still have a separate prod and test environment just like you have now.
I've not done any type of sysplex (base of parallel) with MIM so don't know what you would need to with MIM. It would be helpful if you create CTC connections between the lpars if you do the base sysplex. All that said you could still run into issues even in a base sysplex with sharing a PDSE between the two lpars. Sharing a PDSE is different than sharing a PDS. Technically with PDSESHARING set to NORMAL you only get READ protection between the lpars, there is no write protection. To use the EXTENDED setting you have to be in a parallel sysplex. Thanks.. Paul Feller AGT Mainframe Technical Support -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kevin Mckenzie Sent: Wednesday, July 24, 2019 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sharing PDSEs in shared DASD Environment [EXTERNAL] The very short answer is you shouldn't share PDSEs outside of a sysplex. Under certain circumstances, you can get away with it, but you're just asking for problems. However, I'd note that since you're sharing DASD, and master and user catalogs, you don't really have separate development and production environments. There are a host of ways one environment can affect the other, but without the benefits parallel sysplex (or just sysplex) allows. You could have a parallel sysplex, or sysplex, environment with separate JES2 spools, if you wanted to go in that direction. My official suggestion would be to better isolate the two environments, not try to combine them. There are ways to copy PDSEs between separate environments. --- Kevin McKenzie z/OS Test Services IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 07/24/2019 11:23:16 AM: > From: S B <000001439e1549b6-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/24/2019 11:30 AM > Subject: [EXTERNAL] Sharing PDSEs in shared DASD Environment Sent by: > IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > 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 ---------------------------------------------------------------------- Please note: This message originated outside your organization. Please use caution when opening links or attachments. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
