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" <cfmt...@uniserve.com>
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
000001439e1549b6-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

Reply via email to