I believe that the publication is correct. You cannot do that in a safe way.
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. 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? Peter Relson z/OS Core Technology 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
