I you don't know/have control of which jobs/JCLs that are submitted/run on your systems, would not a logging function in a JES2 exit be a point ? I don't know the technical feasibility of this or if such a function already exist (at CBTTAPE or commercial) but wouldn't that be a great help generally ?
Best Regards Thomas Berg ___________________________________________________________________ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Farley, Peter x23353 > Sent: Tuesday, September 24, 2013 7:39 PM > To: [email protected] > 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
