LLA manages the LNKLST by default. That includes the IPL-time and post-IPL LNKLSTs. New data sets are added to LLA management. Data sets removed from the LNKLST (and no longer in any active LNKLST set) are still managed by LLA unless you have taken overt action to remove them (LLA has a REMOVE statement).
>I am sure for deletion of lnklst datasets I have to refresh/modify >LLA also It can be dangerous to be "sure" when you are wrong. The statement is not true. While LLA Refresh might be "cheap insurance", I agree with Mark Zelden that it should be done only when appropriate, as there can be significant performance ramifications to the system to purging LLA's VLF cache of modules. LLA Refresh is a very bad "rule of thumb". It is safe but overkill. LLA Update is far better (but obviously less convenient since you have to identify what to update) >There used to be applications that did BLDLs of linklist modules. >Refreshing LLA was moot. Compressing those libraries could be >hazardous to those applications. There is nothing wrong with doing BLDL of lnklst modules. Refreshing LLA actually is not moot. Compressing an active LNKLST data set (which is allocated both by LLA and by LNKLST processing in XCFAS precisely to help you avoid that error if you use DISP=OLD for your compress) is simply a horrible thing to do, and you will suffer the consequences and get no sympathy if things go south. >Then there was the co-worker who liked to stage changes in linklist >and not do the LLA refresh until implelemtation time. aghhh... This is actually not a bad strategy, assuming that you use the LLA default of "freeze" for LNKLST data sets. It is in fact part of the reason why "freeze" exists. Peter Relson z/OS Core Technology Design295-8390 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
