Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only "zones" are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments.
New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MIĀ 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 >If you set up new PDS/E program libraries for only V5 program code, >then any time maintenance on a COBOL program is done the maintainer >must be aware whether this is the first time this program has compiled >with V5 and if so, be sure any related production JCL gets changed to >reference the new library in sync with the program installation and be >sure the obsolete load module in some PDS gets purged at the same time >to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link old COBOL programs into PDSEs. Step 4 would be to make sure this works for all systems and that old (unreachable) programs get deleted from PDS datasets Step 5 from time to time, move needed load modules from PDSs to PDSEs until all are moved. Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
