IBM recommends no secondary extents for LNKLST data sets. There will be a health check within the IBM Health Checker for z/OS that checks for exactly that to alert you where you might have an exposure.
Someone mentioned "compress" and "hope". You'd better do more than "hope". z/OS allocates the libraries so that if you do a legitimate compress it won't go through. If you compress a library outside the bounds of what the system allows, please don't ask for help if things don't work any longer for that library. If you refresh LLA (or UPDATE a library in LLA), LLA will update its directory information for all the members of the library. If you then get LLA to cache the member, subsequent LLA fetches of the member will "work". That is a big difficult dangerous "if" even if you use LLA exits. The reason it is even conceivable is because, when LLA updates an entire library, it also closes and re-opens a DCB that it keeps just for that individual library, and when staging a module into its cache it uses that DCB rather than the LNKLST itself for fetching. Thus the staging of a module can "use" new extents. But first you have to get it to do that and in most cases, that will only be after several non-LLA fetches have been done (and those, it sounds like, would fail). As has been discussed before, if you have modules in new extents BUT you don't need those modules accessed from existing address spaces (or can recycle those existing address spaces), then dynamic LNKLST is for you. SETPROG LNKLST DEFINE NAME(NEW) COPYFROM(CURRENT) SETPROG LNKLST ACTIVATE NAME(NEW) all done. 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
