On Sun, 24 Feb 2008 14:23:31 -0500, Peter Relson wrote: >>Of course, an LLA REFRESH (or UPDATE) is also needed to find the new >>member. This could be very useful when a product data set in the linklist >goes >>into another extent, especially if it is a product that can be stopped and > >>restarted. or one that is not constantly in use, such as, for example, a >>compiler. > >In the case I was referring to, namely a new LNKLST set activate, LLA is >automatically updated so that fetches coming from a space using that new >LNKLST set will get the right data.
That's what I thought you were suggesting in your first post in this thread, and it comes as a surprise to me. It means that LLA is not simply managing data sets, as I thought I understood it to do. Rather, it must be managing data sets within linklist sets. As a result, if SYS1.USERLINK is in the LNKLST and I replace a module in it, then create and activate a new linklist set, any new address space referencing that module through the LNKLST will get the new module by virtue of using the new LNKLST. Still, a long running job will continue to get the old copy of the module because it is using the old LNKLST. AFAIK, there is no way for me to tell that this is happening. D LLA does not tell me which LNKLST a library is associated with. When issuing F LLA,UPDATE, to remove a data set from LLA management, there is no way to selectively remove only the one for a particular LNKLST set. Nevertheless, I tested and found that it does behave as you've described. On our sandbox system, I defined a new LNKLST set with my load library at the top. The program that I used to test was SHOWMVS, because I have a couple of releases around and can easily tell which I am running. When I activated the LNKLST, and logged off and back on, I got the module from my library as expected. I then replaced that module with a different release of SHOWMVS, copied the LNKLST set and activated it. I verified that my current TSO session was still picking up the old copy, as expected, then logged off and on again so that I'd be using the new LNKLST set. This time I got the new copy of the module, just as you have described. In these tests, I did not go to additional extents, nor did I want to. Certainly, it sounds safer to define and activate a new LNKLST set when updating a LNKLST library than to perform a REFRESH or UPDATE. Thanks for the tip. -- Tom Marchant ---------------------------------------------------------------------- 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
