That is a well designed system, but IIRC you had the luxury to do it right the first time when you migrated from z/VSE to z/OS. Shops that have been MVS / z/OS since the dawn of time have literally decades of old JCL written to now-obsolete standards to contend with, much of which runs unchanged because it still "just works".
I am not saying this conversion cannot be done, even on a job-by-job basis within particular business applications, but the investment in the SCLM changes is not trivial either, and those changes must support the old compiler as well as the new one so that emergency oh-dark-30 fixes to unconverted code can be made in a timely manner without using the new compiler processes and libraries. I suspect that many large shops will be paying for two compiler versions for quite a long time. Good for IBM, not so good for their customers. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Tuesday, September 24, 2013 12:31 PM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our "load library concatenation". <Details snipped> My point here being that if we needed to add a new application load library to our environment all we need to do is modify 'PROD.APPLIB.INCLUDE(JOBLIB)' and 'PGMR.APPLIB.INCLUDE(JOBLIB)' to add the new library. Frank >________________________________ > From: "Farley, Peter x23353" <[email protected]> >To: [email protected] >Sent: Tuesday, September 24, 2013 6:47 AM >Subject: Re: PDS/E, Shared Dasd, and COBOL V5 > > >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
