A bigger question than whether COBOL V5 requires PDSE load library--yes it does--is why that requirement causes so much consternation in the customer community. Based on discussions at SHARE, I think there are several kinds of qualms.
-- Many seasoned folks still do not trust PDSE. When I entered this biz (late 70s) many folks did not trust VSAM. There was an amusing ditty that circulated in what then passed for email about file types. "If it's ..." The last item went something like: "If it's ... and ... and ... but it doesn't work, it's VSAM". Today there are few open APARs against traditional PDS. Can the same be said for PDSE? -- Few mature shops have standardized on PDSE application load libraries. I'd venture to say that other than those necessitated by program products, including some pieces of z/OS, PDSEs are fairly rare in most shops. -- 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. While sharing a PDS in this way is risky, sharing a PDSE among sysplexes is 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. This is not an objection of the COBOL V5 requirement, just an acknowledgment of customer uneasiness. . . 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 Frank Swarbrick > Sent: Monday, January 25, 2016 09:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: COBOL v5 > > The one reason I know of what a PDSE is required is because TEST/DEBUG > information is now stored in a DWARF NOLOAD segment, and those are only > supported by PDSE (or UNIX directory). > > > Date: Sat, 23 Jan 2016 14:55:31 -0800 > > From: charl...@mcn.org > > Subject: Re: COBOL v5 > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > If by "requires" you mean in some absolute fundamental > > logical/technical sense, you may well be right. This might be a > > "marketing" restriction for all any of us knows. > > > > OTOH I can assure you it requires a PDSE in the sense that if you > > compile a program using COBOL 5.2 and attempt to bind the resulting > > object code into an executable, the binder will fail if SYSLMOD > > references a PDS -- so in that sense I assure you that COBOL 5.2 "requires" a > PDSE. > > > > Charles > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Ed Gould > > Sent: Saturday, January 23, 2016 1:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: COBOL v5 > > > > > > I would argue the word "requires" I suspect (and cannot prove) that > > COBOL 5 can work perfectly fine without a PDSE. > > I would be happy to be proven wrong. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
