What is the downtime when a PDS has to be compressed? We have eliminated the downtimes for PDS compressions by using PDSE. We have not had any problems attributed to PDSE's since we changed the loadlibs from PDS to PDSE.
Regards Otto H Schumacher Transaction and Database Systems - CICS Specialist U. S. Mainframe HP Enterprise Services Telephone +1 864 987 1417 Mobile +1 864 569 5338 Email [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Thursday, September 12, 2013 9:03 AM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 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 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Thomas Conley Sent: Thursday, September 12, 2013 5:40 AM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 On 9/12/2013 8:12 AM, John Gilmore wrote: > Tom Conley wroter: > > <begin extract> > All due respect, the cost to IBM's customer base for converting all > COBOL executable libraries to PDSE will be measured in millions, if > not billions, of US dollars. > </end extract> > > [With] all due respect again, this is empty rhetoric. The last > Decennial Census, of 2010, yielded a US population aged 5-17 of > 53,980,105. Let us now assume, conservatively, that the members of > this group spent an arithmetic mean of US$1.00 per week on junk food > in 2010. > > The 'alarming' result? This group spent US$2,806,965,460 on junk food > in 2010! 'Almost' 3 billion dollars wasted! Etc., etc. The > context-free large-numbers gambit is an old one, but it persuades only > the already persuaded. > > John Gilmore, Ashland, MA 01721 - USA > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN So there's no cost whatsoever to IBM's customer base for converting COBOL executable libraries from PDS to PDSE? My mistake. Here are some context-free, large-numbers gambit empty rhetoric numbers. 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
