Might it be nice to have something other than the LNKLST that behaves as sort of a "global" JOBLIB? I'm specifically referring to for batch jobs, but I imagine it would be useful for TSO as well. In this could be specified those libraries that don't need much of what LNKLST provides (don't ask me what it provides; I'm just an applications developer), but do need a way to apply "globally" to any job that is running.
I imagine something similar to the PROCLIB parm of JES2's JOBCLASS statement. An example: JOBCLASS(?) PROCLIB=00, LOADLIB=00 PROCLIB(PROC00) DD(1)=(DSNAME=SYS2.&SYSNAME..PROCLIB), DD(2)=(DSNAME=SYS2.&ZOSRLVL..PROCLIB), DD(3)=(DSNAME=SYS1.IBM.PROCLIB), DD(4)=(DSNAME=SYS2.&ZOSRLVL..COMPILE.PROCLIB), DD(5)=(DSNAME=SYS3.PROCLIB), DD(6)=(DSNAME=SYS2.PROCLIB), DD(7)=(DSNAME=SYS6.IMD1.PROCLIB), DD(8)=(DSNAME=PGMR.TOOLSLIB.PROC),UNCOND LOADLIB(LOAD00) DD(1)=(DSNAME= ... etc ...) Perhaps different job classes would/could have different PROCLIBs and different LOADLIBs, depending on what applications you run in each class. Probably would be useful to be able to specify more than one set of dynamic DD's as well: JOBCLASS(Q) LOADLIB=(01,00) /* LOAD01 ahead of LOAD00 */ LOADLIB(LOAD00) DD(1)=(DSNAME= ... etc ...) LOADLIB(LOAD01) DD(1)=(DSNAME= ... etc ...) I would imagine, further, that with this in place a JCL JOBLIB/STEPLIB statement could have an option to either override the "class level" JOBLIB or to simply concatenate the JCL DD's ahead of the "class level" DD's. Not knowing things at the system level, it seems workable to me. But I'm sure I'll hear lots of reasons why its a bad idea. So go for it. Frank >________________________________ > From: Juergen Keller <[email protected]> >To: [email protected] >Sent: Wednesday, January 25, 2012 1:51 AM >Subject: Re: PDSE > >Hello all, >thank you for your updates and hints. Lets bring the discussion to an end ... >The "problem" started when we began to install z/OS 1.12 and my colleagues did >not want me to use dynamic steplib in the future (that was another post some >month ago). So we decided to bring this load library to LNKLST. This worked >fine for some weeks. No we wanted to install some maintenance to this library >and this did not work as expected. The library is PDSE and from the posts I >learned that we should not do what I wanted to do. So finally we decided to >remove it from LNKLST and define it as a STEPLIB to the logon-procedure. That >solves all the problems with lnklst and makes it much more easier to install >maintenance. >Bringing a dataset to LNKLST has nothing to do with "chic" or something else. >Its just a way to make lmods available for users in an easy way. All the >following problems when its PDSE and in LNKLST and you want to add/change >lmods where not expected and I was a little bit surprised. By the way ... I'm >not a z/OS-sysprog - only responsible for non-z/OS-software. So I was not >aware of all the restrictions z/OS has. But I know that (I think) a lot of >sysprogs do what they should not do. Yes I understand Peter and Jim and some >others who say what I should not do, whats on my own risk and whats not >supported and and and .... I know some of these problems more than 30 years >and since that time there is no useable supported solution from IBM. But >that's another discussion. >Finally ... this PDSE-library was moved to logon-procedure and removed from >LNKLST and all works fine and we have to live with all the secondary effects. >regards Juergen > >---------------------------------------------------------------------- >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
