One thing to consider is that an INCLUDED JCL member can contain INCLUDE statements, so you if the concern is that the testers want to concatenate libraries ahead of the productions, you could do the following: // SET LVL=PROD // INCLUDE JLSTART // INCLUDE &LVL.JOBL
In member JLSTART you would have //JOBLIB DD DISP=SHR,DSN=SYS1.EMPTY.LOADLIB You could then have a PRODJOBL member with the "standard" files. Developers could then create members with their initials, ie WDJOBL that contain their test libraries, and a last line of // INCLUDE PRODJOBL So all that would need to change is the SET statement. =============================================== Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com =============================================== Frank Swarbrick <[email protected]> Sent by: IBM Mainframe Discussion List <[email protected]> 06/10/2009 07:39 PM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: dynamic allocation >>> On 6/10/2009 at 6:26 PM, in message <listserv%[email protected]>, Paul Gilmartin <[email protected]> wrote: > On Wed, 10 Jun 2009 18:06:01 -0600, Frank Swarbrick wrote: >>> too!". >>>> >>> No caching ==> poor performance. Frequent refresh ==> poor performance. >> >>This is why I would suggest perhaps something similar to LINKLIST in that it > is searched by default, but also like JOBLIB in that there is no caching. >> > No caching ==> poor performance. But we're already having this "issue" by not having application libraries in the LINKLST, yes? How would this make things any worse? >>> Would the JCL INCLUDE facility help you here? >>Yes and no. >> >>Yes, I could have a member that has a JOBLIB concatention with all of the > production libraries I would need for production applications jobs. >> >>But no, this would not help for testing, because any JOBLIB I specified in my > test JCL in order to add a test library (ahead of production libraries) would > have to be "built from scratch" in order to place it at the beginning. >> > For testing, INCLUDE a different JOBLIB member. This in turn (I believe) > could be selected by a JCL symbolic variable which could also be used as > a qualifier in data set names to differentiate your test data from > production data. Perhaps. But each programmer would have to have their own "JOBLIB" member and they would have to all be updated with any libraries added to the production JOBLIB member. (Granted we probably would not update them often so that would probably not be to onerous). Nonetheless I will take it under consideration. Thanks for the idea. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
