>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. In fact, there's a subtlety here such that LNKLST REFRESH would not be a good thing to do. REFRESH (or any UPDATE, but for update pertaining only to the specific information that is the target of the update) tells LLA to synch-up everything and keep only one copy. But for extent situations, it might be functionally necessary to have two (but LLA cannot acocmmodate that after refresh). So now imagine that this is done for member X which appeared in a "new extent". After refresh, when fetched using the new LNKLST set, all is well. When fetched using the old LNKLST set: oops, fetch will fail using the old LNKLST set because the directory entry will have been refreshed and thus will reference the copy in the new extent. I think I have this right. I wouldn't bet that this behavior is well (or even "at all") described. It is basically the behavior you get when you refresh LLA even without multiple LNKLST sets when member X is in a new extent. That doesn't work either. And that all ties to why IBM recommends, and the healch check CSV_LNKLST_EXTENTS "complains" if not met, that LNKLST data sets have no secondary extents. Peter Relson z/OS Core Technologhy Design ---------------------------------------------------------------------- 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
