I can understand putting production level application load libraries into LLA, but not development libraries.
In our shop, which is a very small one, refreshing the development libraries every 15 minutes would be way too infrequent. In DB2 applications it would also cause abends unless you were very careful to co-ordinate your package binds with the LLA refresh. (In most shops the package bind is executed in the same job as the compile+link). On Mon, Jul 27, 2009 at 8:43 AM, Staller, Allan<[email protected]> wrote: > <snip> > 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): > </snip> > > A former employer of mine had user loadlibs in LLA (and I believe > lnklst). They were carried in a separate PROGxx member. > Every (in our case) 15 min, an F LLA,UPDATE=xx was issued by automation. > Not sure what they did when the applications loadlibs needed to be > compressed. > > HTH, > > ---------------------------------------------------------------------- > 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
