These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our "load library concatenation".
We have the following member named 'PROD.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=EMER.APPLIB.LOAD,DISP=SHR // DD DSN=EMER.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS6.IMP1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMP1.DYNLIB.BTCH,DISP=SHR // DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR // DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR In the JES2PARM member we have this: PROCLIB(APPL) DD(1)=(DSNAME=EMER.APPLIB.PROC), DD(2)=(DSNAME=EMER.PEPLIB.PROC), DD(3)=(DSNAME=PROD.APPLIB.INCLUDE), DD(4)=(DSNAME=PROD.APPLIB.PROC), DD(5)=(DSNAME=PROD.PEPLIB.PROC),UNCOND And our jobs look something like this: //DDAR04 JOB ,'DDAR04' //*------------------------------------------------------------------* /*JOBPARM PROCLIB=APPL // SET LOADENV=PROD // INCLUDE MEMBER=JOBLIB //PROC01 EXEC PROC=DDAR04, // DSNENV=PROD, DATASET HLQ // XMTENV=PROD, XMIT DATASET HLQ // IMSENV=PROD, IMS DB HLQ // RDATE=PROD.APPL RUNDATE HLQ // This is for production. For test/qa we have 'PGMR.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=&LOADENV..APPLIB.LOAD,DISP=SHR // DD DSN=PGMR.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS3.IVORYHUB.V511.LOADLIB,DISP=SHR // DD DSN=SYS3.BMC.IMS.IMLIB,DISP=SHR // DD DSN=SYS3.BMC.IMS.BMCPSWD,DISP=SHR // DD DSN=SYS6.IMD1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMD1.DYNLIB.BATCH,DISP=SHR //* DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR //* DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR PROCLIB(APPL) DD(1)=(DSNAME=PGMR.APPLIB.INCLUDE), DD(2)=(DSNAME=PROD.APPLIB.INCLUDE), DD(3)=(DSNAME=PGMR.APPLIB.PROC), DD(4)=(DSNAME=PROD.APPLIB.PROC), DD(5)=(DSNAME=PROD.PEPLIB.PROC),UNCOND To execute a test run from a library named DVFJS.APPLIB.LOAD I would have something like this: //DDAR04 JOB ,'DDAR04' //*------------------------------------------------------------------* /*JOBPARM PROCLIB=APPL // SET LOADENV=DVFJS // INCLUDE MEMBER=JOBLIB 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
