- Too busy driving to stop for gas! -----Original Message----- From: Frank Swarbrick <[email protected]>
Date: Wed, 29 Jul 2009 16:15:29 To: <[email protected]> Subject: Re: Of link lists and application programs I want to thank everyone who has chimed in on this. It sounds like we need to use LNKAUTH=APFTAB instead of the default of LNKAUTH=LNKLST so that our APPL libraries will not be APF authorized when accessed via the LNKLST concatentation (or via a STEPLIB/JOBLIB for that matter). We certainly would not want this. Can someone tell me if I have the following correct? Let's say we have two libraries, SYS2.LIB1 and SYS2.LIB2. Let's further say we have a PROGxx with these entries: APF FORMAT(DYNAMIC) APF ADD DSNAME(SYS2.LIB1) SMS LNKLST DEFINE NAME(LNKLST00) LNKLST ADD NAME(LNKLST00) DSN(SYS2.LIB1) LNKLST ADD NAME(LNKLST00) DSN(SYS2.LIB2) LNKLST ACTIVATE NAME(LNKLST00) Given LNKAUTH=LNKLST: 1a) SYS2.LIB1 is APF authorized when accessed via the LNKLST concatenation. 1b) SYS2.LIB2 is APF authorized when accessed via the LNKLST concatenation. 2a) SYS2.LIB1 is APF authorized when accessed via a JOBLIB/STEPLIB concatenation as long as all other libraries in the concatenation are also APF authorized. 2a) SYS2.LIB2 is unauthorized when accessed via a JOBLIB/STEPLIB concatenation. Given LNKAUTH=APFLIB: 1a) SYS2.LIB1 is APF authorized when accessed via the LNKLST concatenation. 1b) SYS2.LIB2 is unauthorized when accessed via the LNKLST concatenation. 2a) SYS2.LIB1 is APF authorized when accessed via a JOBLIB/STEPLIB concatenation as long as all other libraries in the concatenation are also APF authorized. 2a) SYS2.LIB2 is unauthorized when accessed via a JOBLIB/STEPLIB concatenation. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 7/24/2009 at 5:30 PM, in message <[email protected]>, Frank Swarbrick <[email protected]> wrote: > A little while ago I had posed a question about having "applications" > libraries in the system LNKLST. Some were for it, some were against it. One > of the prominent reasons for being against it was the need to do an LLA > refresh after implementing any changes to an application library. I agreed > that this was a disadvantage and looked around to see if I could get around > it. > > What I found was that you can have libraries *excluded* (removed) from the > LLA. This is done by use of the REMOVE directive in the CSVLLAxx member. I > took my proposal to our systems programmers and here is what they implemented > (in our development system only, so far): > > 'DEVC80.PARMLIB(PROG11)': [no changes, just information] > APF FORMAT(DYNAMIC) > APF ADD > lots off APF stuff > LNKLST DEFINE NAME(LNKLST00) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.LINKLIB) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.MIGLIB) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.CSSLIB) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.SIEALNKE) > lots more system libraries > LNKLST ACTIVATE NAME(LNKLST00) > > 'DEVC80.PARMLIB(PROGAP)': [these are the PROD APPL libraries to go in > LNKLST] > LNKLST DEFINE NAME(LNKLSTAP) COPYFROM=CURRENT > LNKLST ADD NAME(LNKLSTAP) DSN(PROD.APPL.DFSRESL) VOLUME(PRO101) > LNKLST ADD NAME(LNKLSTAP) DSN(EMER.APPL.LOADLIB) VOLUME(TSO001) > LNKLST ADD NAME(LNKLSTAP) DSN(PROD.APPL.LOADLIB) VOLUME(PRO108) > LNKLST ACTIVATE NAME(LNKLSTAP) > > 'DEVC80.PARMLIB(IEASYS11)': [loads the four PROGxx members] > PROG=(11,CI,DB,AP) PROGCI and PROGDB are other system libraries (CICS and > DB2 respectively) These used to all be in PROG11, but it looks like someone > started splitting them out. Good for them! > lots of other stuff > > 'DEVC80.PARMLIB(CSVLLAAP)': [remove prod appl libs from LLA!!] > REMOVE(EMER.APPL.LOADLIB, PROD.APPL.DFSRESL, PROD.APPL.LOADLIB) > > 'DEVC80.PARMLIB(IEACMD00)': [start LLA, invoking the CSVLLAAP member > instructions] > COM='START LLA,SUB=MSTR,LLA=AP' > > From my perspective this works exactly as I, an applications developer, > desire. It has neither the advantages nor the disadvantages of LLA > controlled libraries. I am fine with this. > > Systems is concerned about system integrity. Rightly so. LNKLST has > historically been for systems libraries only. But since there is no similar > facility for business applications libraries this seems to be the only way I > can get what I want. In any case, does anyone see any obvious issues with > this? One concern is that the APPL libraries would automatically become APF > authorized, which of course is a no-no. That does not *appear* to have > occured: > > /D PROG,LNKLIST > RESPONSE=ZOSD > CSV470I 17.22.12 LNKLST DISPLAY 224 > LNKLST SET LNKLSTAP LNKAUTH=LNKLST > ENTRY APF VOLUME DSNAME > 1 A DEVR80 SYS1.LINKLIB > 2 A DEVR80 SYS1.MIGLIB > 3 A DEVR80 SYS1.CSSLIB > 4 A DEVR80 SYS1.SIEALNKE > etc. > 60 A DB2001 SYS3.DSN910.SDSNEXIT > 61 A DB2001 SYS3.DSN910.SDSNLINK > 62 DB2001 SYS3.DSN910.SDSNLOD2 > 63 A DB2001 SYS3.DSN910.SDSNLOAD > 64 *SMS* PROD.APPL.DFSRESL > 65 *SMS* EMER.APPL.LOADLIB > 66 *SMS* PROD.APPL.LOADLIB > > /D PROG,APF does not show the APPL libraries. > > /D LLA does not show the APPL libraries. > > All of the above are as I would expect. > > The only concern I have at this point, and it's a very very minor one, is > that if you add an application library to the LNKLST you also have to > remember to REMOVE it from the LLA. But since I don't anticipate there being > changes often or at all (after implentation) to these I'm not too worried. > > Thanks! > Frank >>> 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
