Re: Sharing PDSEs in shared DASD Environment
[Default] On 24 Jul 2019 12:23:41 -0700, in bit.listserv.ibm-main d...@bkassociates.net (Doug) wrote: >You cannot share PDSE's across systems not in a Sysplex. Period. If you >want to share PDSE's, you have to have the systems in the same sysplex. >You do not need a JESPlex, but I believe you will need a GRSPlex to >accommodate the enqueues. If you share them, and particularly write to >one, you will need to refresh the incore data from the dataset. There >are procedures to do that. You may have to restore, but not always. I >went through this for a couple of months a couple of years ago, and >there was no other option. Make them non PDSE's if you need to share. >You may be able to get away with only reading from one, but even that is >dicey. Simple answer I got from IBM support: Don't do it. Given the number of shops that were sharing PDSs either within sysplex boundaries or between them, I am surprised that IBM seemed to neither find a way to allow at least limited PDSE sharing across boundaries nor provide mechanisms that would allow the shops that were doing sharing to meet those needs they believed were / are only satisfied by sharing. A system of master and mirror data sets with an appropriate mechanism for triggering and doing the updates probably could work for many shops. Clark Morris > >Doug > >Doug Fuerst >d...@bkassociates.net > >-- Original Message -- >From: "Clark Morris" >To: IBM-MAIN@listserv.ua.edu >Sent: 7/24/2019 3:12:33 PM >Subject: Re: Sharing PDSEs in shared DASD Environment > >>[Default] On 24 Jul 2019 08:24:17 -0700, in bit.listserv.ibm-main >>01439e1549b6-dmarc-requ...@listserv.ua.edu (S B) 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 >> >>My complaints about PDSE are that it is even less safe to share PDSEs >>across sysplexes than it is to share PDSs and that PDSEs are not >>available at NIP, i.e. SYS1.NUCLEUS, SYS1.PARMLIB, SYS1.LPALIB, >>SYS1.LINKLIB and other IPL data sets must be PDS's and not PDSEs. The >>former problem may be taken care of enough by allowing sysplex sharing >>if that mechanism also can handle GDPS. The latter problem in my >>rarely humble opinion was the same customer surly short-sightedness >>that didn't allow SNA 327x devices to be consoles at NIP. The PDSE >>restriction bars a path to migrating to FBA just as the latter >>restriction required my employer to have 2 Bi-Sync local 327x >>controllers to avoid single points of IPL failure. >> >>Clark Morris >>> >>> 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 DA
Re: Sharing PDSEs in shared DASD Environment
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 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 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 > 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
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 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 > 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
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 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
Re: Sharing PDSEs in shared DASD Environment
You cannot share PDSE's across systems not in a Sysplex. Period. If you want to share PDSE's, you have to have the systems in the same sysplex. You do not need a JESPlex, but I believe you will need a GRSPlex to accommodate the enqueues. If you share them, and particularly write to one, you will need to refresh the incore data from the dataset. There are procedures to do that. You may have to restore, but not always. I went through this for a couple of months a couple of years ago, and there was no other option. Make them non PDSE's if you need to share. You may be able to get away with only reading from one, but even that is dicey. Simple answer I got from IBM support: Don't do it. Doug Doug Fuerst d...@bkassociates.net -- Original Message -- From: "Clark Morris" To: IBM-MAIN@listserv.ua.edu Sent: 7/24/2019 3:12:33 PM Subject: Re: Sharing PDSEs in shared DASD Environment [Default] On 24 Jul 2019 08:24:17 -0700, in bit.listserv.ibm-main 01439e1549b6-dmarc-requ...@listserv.ua.edu (S B) 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” My complaints about PDSE are that it is even less safe to share PDSEs across sysplexes than it is to share PDSs and that PDSEs are not available at NIP, i.e. SYS1.NUCLEUS, SYS1.PARMLIB, SYS1.LPALIB, SYS1.LINKLIB and other IPL data sets must be PDS's and not PDSEs. The former problem may be taken care of enough by allowing sysplex sharing if that mechanism also can handle GDPS. The latter problem in my rarely humble opinion was the same customer surly short-sightedness that didn't allow SNA 327x devices to be consoles at NIP. The PDSE restriction bars a path to migrating to FBA just as the latter restriction required my employer to have 2 Bi-Sync local 327x controllers to avoid single points of IPL failure. Clark Morris 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
Re: Sharing PDSEs in shared DASD Environment
[Default] On 24 Jul 2019 08:24:17 -0700, in bit.listserv.ibm-main 01439e1549b6-dmarc-requ...@listserv.ua.edu (S B) 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 My complaints about PDSE are that it is even less safe to share PDSEs across sysplexes than it is to share PDSs and that PDSEs are not available at NIP, i.e. SYS1.NUCLEUS, SYS1.PARMLIB, SYS1.LPALIB, SYS1.LINKLIB and other IPL data sets must be PDS's and not PDSEs. The former problem may be taken care of enough by allowing sysplex sharing if that mechanism also can handle GDPS. The latter problem in my rarely humble opinion was the same customer surly short-sightedness that didn't allow SNA 327x devices to be consoles at NIP. The PDSE restriction bars a path to migrating to FBA just as the latter restriction required my employer to have 2 Bi-Sync local 327x controllers to avoid single points of IPL failure. Clark Morris > > 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
Re: Sharing PDSEs in shared DASD Environment
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 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=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8Ldrrv > xQb- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=uAUpHjYU3mGwLx5ErYtDwQF- > 4Yd0E2So1uiOo1RJJDM=Z_ByYRZvSvYlMRpj12KIhN_rJF0jOwSLEvfqPx4PSh > s= > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, July 24, 2019 2:51 PM, Gibney, Dave > 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
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://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, July 24, 2019 2:51 PM, Gibney, Dave 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
Re: Sharing PDSEs in shared DASD Environment
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 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
Re: Sharing PDSEs in shared DASD Environment
CA MII doc also says that PDSESHARING(extended) is unsupported across Sysplexes. " CA MII is fully compatible with PDSE resource sharing. CA MII does not modify, enhance, or restrict PDS/E processing in any way. PDSE sharing is limited to a single sysplex in a pure global GRS environment, and the same restrictions apply, even when you are running CA MII. In this regard, CA MII neither enhances nor restricts PDSE sharing." I think you are between a rock and a hard place. Perhaps reverting to PDSESHARING(NORMAL) and using DISP=OLD to avoid the sharing error. RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kevin Mckenzie Sent: Thursday, 25 July 2019 02:02 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Sharing PDSEs in shared DASD Environment 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 wrote on 07/24/2019 11:23:16 AM: > From: S B <01439e1549b6-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 > > 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
Re: Sharing PDSEs in shared DASD Environment [EXTERNAL]
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 wrote on 07/24/2019 11:23:16 AM: > From: S B <01439e1549b6-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 > > 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 --
Re: Sharing PDSEs in shared DASD Environment
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 wrote on 07/24/2019 11:23:16 AM: > From: S B <01439e1549b6-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 > > 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
Re: Sharing PDSEs in shared DASD Environment
Starting SMSPDSE1 and enabling PDSESHARING=EXTENDED won't fix Ops problem. Their systems are not in a SYSPLEX, hence PDS/e's can't be shared. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, July 24, 2019 11:32 AM, Allan Staller wrote: > PDSESHARING=EXTENDED and start SMSPDSE1 > SMSPDSE (address space) is for "system tasks" SMSPDSE1 is for "user tasks" > Check the fine manuals. > > This is an SMS issue, not a MIM issue. > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of S B > > Sent: Wednesday, July 24, 2019 10: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 > ::DISCLAIMER:: > > --
Re: Sharing PDSEs in shared DASD Environment
PDSESHARING=EXTENDED and start SMSPDSE1 SMSPDSE (address space) is for "system tasks" SMSPDSE1 is for "user tasks" Check the fine manuals. This is an SMS issue, not a MIM issue. -Original Message- From: IBM Mainframe Discussion List On Behalf Of S B Sent: Wednesday, July 24, 2019 10: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 ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
