You are correct. Just thought I'd mention it! I definitely feel for you. I continue to wish for some sort of "job class level" load library concatenation that would "sit" between JOBLIB/STEPLIB and the system link list. I don't feel I know enough about MVS internals to make a good RFE for this. But if someone has thoughts...
Frank >________________________________ > From: "Farley, Peter x23353" <[email protected]> >To: [email protected] >Sent: Tuesday, September 24, 2013 11:38 AM >Subject: Re: PDS/E, Shared Dasd, and COBOL V5 > > >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 > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
