I am probably veering the topic.. or into oncoming traffic.. but.. why let that dissuade me? <VBG>
STEPLIB/JOBLIB is marked as being APF or not-APF when it is referenced (my understanding... I am sure there is a more accurate description ). I am assuming that to maintain integrity, the dynamic STEPLIB would have to (I think my mind just exploded for a moment) 1) lookup whether it was eligible for dynamic STEPLIB 2) muck with the DEB to mark it non-APF if any of the dynamic STEPLIBs were not APF 3) at least verify that if the JCL STEPLIB were APF, that the dynamic portion would have to match ugh.. and then what if you wanted it to be Special and do something with a little less integrity? Security check first? Can't this just be accomplished via JES2 exit and just modify the JCL thus leaving the normal STEPLIB integrity alone? Or am I just being a bit dull on this Friday and cannot see a use-case? Rob Schramm On Fri, Sep 22, 2017 at 3:53 PM David W Noon < 0000013a910fd252-dmarc-requ...@listserv.ua.edu> wrote: > On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell > (walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?" > (in <4974758334821366.wa.walt.farrellgmail....@listserv.ua.edu>): > > > On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com> > wrote: > > > >> Dynamic STEPLIB has been discussed in these fora so often that I suspect > >> it's the subject of numerous RFEs. I suspect there are technical > reasons > >> that IBM has not rushed to provide the function. Is the design of > OS/360 > >> such that any dynamic STEPLIB would be incomplete or have unintended > >> consequences? > > > > Any dynamic STEPLIB functionality introduces potential System Integrity> > exposures, because some parts (modules) of a program may have been > loaded> from one library and others from a different, incompatible library. > Such an exposure can just as easily occur from a static concatenation > for STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant > increase in such exposure. > > It is up to the site's programmers to ensure that the load libraries in > use in a job step are mutually compatible. > -- > Regards, > > Dave [RLU #314465] > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > david.w.n...@googlemail.com (David W Noon) > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
