On 25 Jan 2016 10:24:42 -0800, in bit.listserv.ibm-main you wrote: >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?
I know that I am in a minority when I say that IBM should be transitioning to FBA for z/OS. This would mean that all FBA file types: KSDS, ESDS, RRDS, Linear, PDSE, and UNIX are readable at IPL time. SYS1.NUCLEUS could be either merged with NIP or put in either a PDSE or UNIX file system. An appropriate UNIX file structure would be the alternative SPOOL for both JES2 and JES3 (idea snitched from my time contracting at a site with HP-UX). ESDS data sets would have to have a GDG equivalent capability and tools for converting JCL would have to created. If UNIX file systems have all of the capability of PDSE for load modules (and other uses) maybe PDSE should be functionally stabilized. An alternative would be to make PDSEs readable across sysplex boundaries. I find it ludicrous that started tasks are needed to read basic file structures such as PDSE and UNIX FS. It reminds me of my frustration that we couldn't use our local channel attached SNA 3270s for consoles back in the 1980s. We needed to have 2 non-SNA controllers so that the controller wasn't a single point of failure for IPL. How reliable is PDSE these days? Clark Morris > >-- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
