I believe Tom Ross explained this, but some might have missed it. The main reason, from what I've heard, is so that the 'debug' data can be stored in a no-load segment of the program object. Thus the debug data will not be (automatically) loaded in to memory at execution time, but will be loaded only if requested by a tool such as IBM Fault Analyzer or IBM Debug Tool. This eliminates the long standing hassle of keeping the debug data "in sync" with the executable. And I for one welcome it!
And while I forsee some effort to convert our executable libraries from PDS to PDSE, and while we haven't come up with our plan for doing so, I don't see it as being as big a hassle here as it will be in other shops. It will certainly take an outage so that the conversion can be run while no applications are accessing the libraries, but we have only a few production ones. >________________________________ > From: Thomas Conley <pinnc...@rochester.rr.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Thursday, September 12, 2013 9:22 AM >Subject: Re: PDS/E, Shared Dasd, and COBOL V5 > > >On 9/12/2013 9:03 AM, Lizette Koehler wrote: >> Tom, >> >> I might suggest you underestimated the outage time and costs. For the >> compiler and source management software - probably 2 hours. >> >> But to change out all of the load libraries into PDS/E datasets - much >> longer. >> >> That will impact any function in z/OS that runs production code. So assume >> that joblibs/steplibs in any DB2 Stored procedure, CICS STC DFHREPL, IMS >> STCs DFSRESLB, MQ STCs, and all batch JCL have to change. That outage could >> a huge impact. >> >> I do not see the conversion from PDS to PDS/E big if all rules are followed. >> But if I have an application load library that needs to be changed from PDS >> to PDS/E that is in all of the above mentioned JCL, then I have to have >> everything come down on all systems at one time. That could be a much >> longer window and almost a Plex wide outage. >> >> Yes, one could start by putting in an empty PDS/E above the PDS in all of >> the above mentioned JCL and then over time get things straightened out. I >> could not start loading that PDS/E until all the application JCL has also >> had it added. >> >> Yet, even with a pre-staging of the PDS/E into the JCL. Our shop, for >> example, has not cycled some of these types of tasks for over 4 months. Our >> time line to change to PDS/E in these tasks (CICS, IMS, MQ, DB2, etc...) >> would be at least 6 months or so for a normal process. To cycle these tasks >> sooner could take an act of some deity. >> >> For the application group much longer to start changing all of their >> steplibs and joblibs. They have more work, because, even if it is a benign >> change like adding one DD statement to the steplib/joblib - that JCL has to >> go through all the normal checkout processes. QA, Unit test, Validation, >> change control, etc.... That could take up to a year or so; however, if >> you have 60k or so product batch JCL (and you do not know which ones are >> really live), it could take even longer. Therefore, until all the >> application JCL has been updated, the STCs would continue to have an empty >> PDS/E dataset. That is where I see the issue. >> >> So one version of this plan, how change all PDS to PDS/E for load modules, >> would be to start with forcing the Change Management Software to include an >> empty PDS/E into all JCL that goes through it for steplib and joblib. >> System folks would start by placing the same empty PDS/E into the JCL they >> manage. Lastly the shop's management would need to assign a group of >> application folks to focus on review and changing the remaining JCL for >> production. It will be almost like a Y2K effort. There would also need to >> be an analysis of how many PDS/E Datasets will be needed. >> >> As some applications will have unique PDSs for their applications so tasks >> like the CICS DFHRPL may not have 1 PDS for application load modules but >> MULTIPLE PDS datasets. And your storage admin folks will also need to be >> involved as some load libraries are huge and there would need to be two of >> everything until the conversions complete - 1 PDS (current) 1 PDS/E - future >> replacement. >> >> >> Just my $0.02 worth. >> >> Lizette >> >> ><snip> >> Let's assume 1000 COBOL licenses in the world, with 100 executable >> datasets per license (IMNSHO, ridiculously conservative estimates). So >> that's 100,000 executable datasets. I'll set, again, a conservative >> estimate of $1,000 to convert the PDS to PDSE. Here is how I break that >> down. Planning - 1 hour. Allocating and copying - 1 hour. Change control >> paperwork - 2 hours. Implementation - 2 hours. >> Post-implementation followup - 2 hours. That's 8 hours at a fully-burdened >> rate of $125/hr. I haven't even figured in the cost of DASD. That's $100M >> US just to convert this small scenario I've laid out here. >> >> This is the last time I'll ever respond to a post by John Gilmore. >> >> Regards, >> Tom Conley >> > >Lizette, > >Great analysis of some of the operational costs involved in this PDS to >PDSE conversion just to support COBOL V5.1. In many shops, this will >not be a trivial exercise, as some on IBM-Main have stated. This will >be a serious migration effort, and cost significant dollars. I'm still >mystified as to why IBM felt it had to impose this completely >unnecessary restriction. What reason is there to force COBOL V5.1 >executables to come from a PDSE? > >Regards, >Tom Conley > >---------------------------------------------------------------------- >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
