All, A few (IMHO) clever syprogs I've worked with simply had a small, empty "emergency" PDS at the head of linklist. New or zapped modules were simply put there followed by an LLA refresh. Subsequent linklist searches would pick up the new modules from this library.
The changed modules would be retrofitted to the appropriate library and the emergency library emptied at next maintenance IPL. Is this still a valid practice? Something that is not clear to me. A zapped module is updated in place, therefore it seems to me that an LLA Refresh is not required as the directory has not changed. Is this correct? Another thing that is not clear to me: an LLA Refresh does not cause VLF you throw away all it's cached linklist members, correct? If so, then how is a zapped module invalidated in VLF if the directory is not changed? Is there some sort of notify event from the Zap? Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Peter Relson > Sent: Friday, 5 May 2006 7:39 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: LINKLST into EXTENTS > > 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 ---------------------------------------------------------------------- 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
