Hi Lizette. Definitely food for thought.
We come from the VSE world, being on z/OS only since 2010, so I still have a VSE mindset in many ways. In VSE there is a JCL card called LIBDEF, which has parameters PROC, PHASE, SOURCE, OBJ, and DUMP. For example: // LIBDEF PROC,SEARCH=([system libraries here],USER.PROD),PERM // LIBDEF PHASE,SEARCH=([system libraries here],USER.PROD),PERM // LIBDEF SOURCE,SEARCH=([...]),PERM // LIBDEF OBJ,SEARCH=([...]),PERM If TEMP is specified instead of PERM (both are omitted; TEMP being the default) the the LIBDEF is only in place for the duration of the job. With PERM specified the LIBDEF becomes the default for the partition (class) in which it was submitted. So at IPL something like the above is submitted to each partition. This allows jobs to have no LIBDEF statement at all, if only the default libraries are desired. If a developer wishes to have a "private" library search first all they need to do is add a TEMP LIBDEF to their test JCL, e.g.: // LIBDEF *,SEARCH=FJS.MYLIB "* Indicates that the LIBDEF statement applies to all member types except DUMP and user types". (Hmm, "user types"? Hadn't heard of that before. Sounds interesting!) So in essence, I am trying to get as close to that functionality in z/OS as I can. It's a struggle. At this point all of our application jobs have the following immediately following the JOB card: /*JOBPARM PROCLIB=APPL // SET LOADENV=PROD // INCLUDE MEMBER=JOBLIB JOBPARM PROCLIB is obviously used to point to the JES2 PROCLIB APPL concatentation. If a developer wishes to have a private library searched first they can just add a JCLLIB statement. We've been running this way, as mentioned, since May of 2010 and I don't believe we've ever run in to any issues with compressing our PDS proclibs. And as I stated above, its simple to add a JCLLIB for personal libraries. The member JOBLIB is in one of the libraries that is included in the APPL PROCLIB concatentation. The development one looks like this: // SET IMSID=IMD1 //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.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.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR The DD's specified are: - A parametrized "private" load library. See note below - A shared programmer test load library - The three production application load libraries - Some system load libraries that are not present in LNKLST If a developer wants to execute a non-production executable they compile it to their <pgmrhlq>.APPLIB.LOAD library and they change the "SET LOADENV" to specify their personal HLQ. Our production JOBLIB is something like this: // SET IMSID=IMP1 //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 Similar, but it includes our EMER libraries, and does not include our PGMR test library nor (intentionally!) any way of specifying a user's personal library. All of this works, but I am still not really happy with it. It seems to be kind of 'ad-hoc'. In VSE the systems programmers were in charge of changing their IPL proc specified PERM LIBDEF statements if they want to add a system library (like SDFHEXCI, for example) for use by applications, or if they want to implement a new version that exists in a different library. (That's somewhat less important now, because where we previously had something like CICS.V410.SDFHEXCI, they have now specified an ALIAS CICS.SDFHEXCI that is to always point at the desired version. We'll see how well that works when we upgrade to CICS TS 5.1.) Anyway, my point here is that even though systems would install a new version (of McKinney Batch to CICS, for example), our applications would not use it until we changed the name in the JOBLIB member. Since technically that member was an "applications member" they didn't want to touch it; they had us do it. But as I said, hopefully the use of aliases will mitigate this issue. I do find it a bit of a "kludge" the way we implemented the use of a JCL parameter (LOADENV) so we can use this include member and still be able to override it. It doesn't work at all if one wants to specify two test libraries (or even one that does not meet the standard naming convention). I imagine we could make the JOBLIB include something like this: // 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.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.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR And the jobs could have this: /*JOBPARM PROCLIB=APPL //JOBLIB DD DISP=SHR,DSN=PROD.DUMMY.LOAD // INCLUDE MEMBER=JOBLIB That's a little more flexible, since one can specify whatever name they want in place of "PROD.DUMMY.LOAD", and can add additional DD statements as well. To be honest I'm not sure why I didn't decide to go this way. I'm not a fan of the "dummy" library, but I think it would be necessary to get this to work as I want. Doing a conversion to this shouldn't be too difficult using some REXX automation. But in the end I would prefer to not have any of these lines in production JCL. I can't eliminate the JOBLIB related stuff, because there is no way to specify default execution libraries, other than using methods that systems won't let us use (LNKLST, etc.). I would actually love to have something like the default JES2 PROCLIBs for application load modules. Anyway, I am really rambling. But I hope I've made some of my desires, and the reasons behind them, clear. I am always up for any good suggestions. Frank >________________________________ > From: Lizette Koehler <stars...@mindspring.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Thursday, August 30, 2012 7:17 AM >Subject: Re: JES2 JOBCLASS PROCLIB > >Frank, > >You need to be thinking about support vs. micromanagement. > >In large shops the use of JCLLIBs are controlled via the Change control >Process (Changeman, Endevor, Homegrown) or products like JCLPLUS or PROJCL, >etc... And job scheduling Software could also be impacted. > >With JCLLIBs you can allow the programmers to not be bothering the sysprogs >every time they need a new proclib added or compress a proclib dataset. > >This is particularly helpful during Q/A, Testing or other processes used >prior to going to production. > >However, as I said, the 00/nn is only numeric. And you will need to get the >sysprogs to agree to this process. I know your shop is not large so it will >probably work. But since JCLLIB is documented, at some point a clever >programmer will find it and start using it without you seeing it. Then you >will need to determine how to control that usage. > >Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf >> Of Frank Swarbrick >> Sent: Thursday, August 30, 2012 3:48 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: JES2 JOBCLASS PROCLIB >> >> I prefer JCLLIB to be used only for proclib overrides. For our standard >set of >> application procs I prefer they either not be specified explicitly at all >(JES2 class >> default), or at the very least be specified simply (using the JOBLIB >PROCLIB >> statement). That way we don't have people not using the standard set of >application >> proclibs. >> Frank >> >> >> >> >> >________________________________ >> > From: Lizette Koehler <stars...@mindspring.com> >> >To: IBM-MAIN@LISTSERV.UA.EDU >> >Sent: Wednesday, August 29, 2012 6:38 PM >> >Subject: Re: JES2 JOBCLASS PROCLIB >> > >> >Frank, >> > >> >You do not need to put PROCLIBs in JES2 if you do not want to. >> > >> >Instead look at the JCLLIB statement in JCL. >> > >> >Or do you require the use of the PROCLIB statements? >> > >> >For application users, I prefer they use JCLLIBs rather than relying on >> >JES2 Proclibs >> > >> >Lizette >> > >> > >> >> -----Original Message----- >> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> >> On >> >Behalf >> >> Of Frank Swarbrick >> >> Sent: Wednesday, August 29, 2012 4:10 PM >> >> To: IBM-MAIN@LISTSERV.UA.EDU >> >> Subject: JES2 JOBCLASS PROCLIB >> >> >> >> We have the following: >> >> >> >> JOBCLASS(?) AUTH=ALL, /* All commnds accepted >> >> [...] >> >> PROCLIB=00, >> >> [...] >> >> >> >> PROCLIB(PROC00) DD(1)=(DSNAME=SYS2.&SYSNAME..PROCLIB), >> >> [...] >> >> >> >> PROCLIB(APPL) DD(1)=(DSNAME=DEV.APPLIB.INCLUDE), >> >> [...] >> >> >> >> In our "application" jobs we specify: >> >> /*JOBPARM PROCLIB=APPL >> >> >> >> It looks like in the JES2 parmlib member the following limitation is >> >> in >> >place: >> >> PROCLIB=nn|00 >> >> Specifies the default procedure library number (00-99) which is to >> >> be >> >used for this >> >> job class. >> >> >> >> Am I missing something, or is the use of the JOBPARM JES2 JCL >> >> statement >> >the only >> >> way that a non-numeric JES2 PROCLIB concatentation can be referred to? >> >> >> >> Obviously we could just rename PROCLIB(APPL) to something like >> >> PROCLIB(10) >> >and >> >> then add something like JOBCLASS(A) PROCLIB=10, so any job executing >> >> in >> >CLASS=A >> >> will use the "applications" proclib, PROCLIB=10. I would prefer >> >> being >> >able to say >> >> PROCLIB=APPL or something, because "APPL" has more implicit meaning >> >> than >> >"10". >> >> >> >> I am not a sysprog and cannot test this out myself. I want to >> >> suggest it >> >to our >> >> sysprogs, but I want to make sure I am suggesting something that can >> >> be >> >done. >> >> >> >> Thanks! >> >> Frank >> >> >> > >> >---------------------------------------------------------------------- >> >For IBM-MAIN subscribe / signoff / archive access instructions, send >> >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >> > >> > >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, send email >to >> lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
