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 <[email protected]>
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 [email protected] with the message: INFO IBM-MAIN
