Frank, I totally understand. Unfortunately the translation from VSE to JES2 is not - shall we say - valid. The environments are very different in their philosophy.
So, a little history. In the past (SVS, MVS, MVSXA) the proclib datasets were hardcoded into the JES2 Startup Proc. So what would happen is the application group would be adding lots of procs to their datasets and then all of a sudden get an x37 abend. So they would compress their library, but JES2 loads the procs TTR entries into her (okay its) address space and suddenly get I/O errors. You either had to shut down JES2 or do an close/open on the PROCxx DD. When JES2 went to more dynamic proclibs, they removed the need to have them in the JES2 Startup Proc and created statements in the JES2 Deck to handle the Proclibs. This was desperately needed, but they kept the same process - PROCxx statements replaced the PROCxx DD Statements. This probably allowed them to more quickly implement this change without having to change too much of the code. Probably more of a front end type process with the original code let mostly alone. So you can see that the process was not really (in my opinion) really looked at as an enhancement with a better process. But rather just get it out of the STC and into the JES2 Deck. This leads me to suspect that the code they were dealing with inside JES2 would have been a major problem had they rewritten it to be more flexible. Instead we have $TPROCLIB, $DPROCLIB commands, JCLLIB and PROCxx statements in the JES2 Deck. There is also the INCLUDE MEMBER statement in JCL where you can maintain JCL statements that can be made common and only have one place to change it. Not elegant but solved the issue. Which was to remove the need for the sysprog to maintain the PROCLIB concatenation in JES2, Allow end users to handle their own proclibs and remove the potential issue with JES2 errors on the Procs held by TTR inside the address space. So your shop needs to determine how best to help your users 1) Do you have a change control product (Changeman, Endevor, other)? If so, it can enforce the use of proclibs (Via JCLLIB) in the production JCL 2) Do you have a product to valid JCL (JCLPLUS, PROJCL, other)? If so, you can really enforce or rewrite JCL with these products. 3) How much control do you want to be in which area? Are programmers allowed to setup their own JCL Procs and test with them and then promote them to production? Or will some other group be the Controllers? Not really what you wanted but hope it helps some. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of Frank Swarbrick > Sent: Thursday, August 30, 2012 9:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 JOBCLASS PROCLIB > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
