Thanks for your input, Peter: >The system will use the LNKLST as it was defined because it has built and >opened a DCB representing the concatenation. >LLA will use the data sets as they are cataloged. LLA allocates each data >set that it is managing. And it uses the catalog to locate that data set. >This is no different than the requirement that even if you specify both the >name and volume when identifying your IPL-time LNKLST data sets, the data >set still must be cataloged on that volume, in the catalog that LLA uses.
I would have to argue that to obtain the current linklist concatenation, LLA is most likely looking at the current linklist data set list in memory, and not trying to use the parmlib progxx members to piece it together. The volsers are right there. Why not use them? >The ONLY way to do what you want is still unpredictably dangerous. >As is mostly documented (it is really intended for getting rid of data sets >that you have a pressing need to get rid of), > Use LNKLST UNALLOCATE (SETPROG or PROGxx) to get rid of the LNKLST >ENQs > Stop LLA to get rid of LLA's ENQs > The previous steps are related to my presumption that you cannot > recatalog data sets for which the SYSDSN ENQ is held> > Recatalog your data sets > Use LNKLST ALLOCATE to resume LNKLST ENQ processing > Create a new LNKLST set > Activate the new LNKLST set > Get ALL users off of the old LNKLST set(s). Presumably that is via > LNKLST UPDATE. If that trashes your system, then so be it. That is the > risk you take when you do this. There is nothing to prevent it, there is > nothing that will or can be done about it. > Restart LLA >So the choice is yours to take: is it more important to recatalog the data >sets than to be sure your system stays up? I prefer predictability. It is most important that the software work in a reliable and predictable manner. And, of course, the documentation should be accurate as well so that predictability does not become a crystal ball adventure. Yes, of course the systems must stay up, and the data sets must be moved. Both must occur, so it is not a matter of choice. That being the case, since the only 'officially' recommended solution is to risk a major outage, I decline to follow convention. Alternative 1: Does anyone have thoughts about using DSS or another utility to make an exact copy of the linklist library on another volume, such that the internal TTRs will remain the same? I would expect this to allow LLA to read the wrong data sets but get the right information in its tables. Alternative 2: Disable LLA until the next IPL Alternative 3: Wait to recatalog the data sets until immediately before the next scheduled IPL. ---------------------------------------------------------------------- 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
