PDS/PO has been enhanced over the years, including a specific abend code, S213-30, to indicate that a PDS is already open for output when another task tries to update it. AFAIK that test works only within a system or at most a sysplex. But (shooting from the hip in my new post-employment mode) PDSE gets additional protection by way of sysplex itself. This function was to satisfy ancient customer demand for additional data integrity. In other words, if you want rock solid data integrity, move to PDSE and share it only within a single sysplex.
Nothing says you'll die an immediate grotesque death by sharing partitioned data sets among sysplexes, but you're venturing into dodgy territory. Like B movie teenagers who don't see a problem with making out in the woodshed. They may get out alive, but don't bet on it. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Monday, January 25, 2016 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: COBOL v5 > > On 2016-01-25 11:24, Skip Robinson wrote: > > > > -- Here's a serious inhibitor for some shops. Despite decades of > > advice to the contrary, some shops still share application load > > libraries across sysplex boundaries. This practice dates back to pre-sysplex > configurations. > > > In our case, in our test environment, we share load libraries across sysplex > boundaries because we have more systems at a wider range of releases than > sysplex supports. (We support OS releases at more levels than IBM. Many ISVs > do likewise; it's our added value.) > > > While sharing a PDS in this way is risky, sharing a PDSE among > > sysplexes is > > > What are the risks to sharing a PDS that way? AFAIK, z/OS for many releases > has provided serialization of PDS directory updates. This avoids directory > corruption. Otherwise, it's the responsibility of an administrator to assure that > all updates of shared PDS are performed from a single system, or otherwise > serialized. > > > a recipe for disaster because only sysplex understands PDSE. It's not > > GRS or ISV equivalent; it's sysplex itself. (I don't know the > > technicality of this > > limitation.) You cannot just convert a shared PDS to a PDSE. You have > > to change your application load module management practices to support > > multiple targets. If you have product or RYO code that migrates a load > > module from DEV to PROD, you have to change the process to migrate > > from DEV to PROD1, PROD2, ... PRODn. Depending on your configuration > > and migration process, this could be a big deal. This change has to be > > completed before the first COBOL V5 load module moves to production. > > > AFAIK, NFS suffers no such restrictions or risks. I'd welcome support of > //STEPLIB DD PATH='/...' and similar for LINKLIST. UNIX executables support > Program Objects. IBM should consider this as a solution. > > Can COBOL v5 objects be bound into UNIX files? > > -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
