It depends on what you call frequently. Our IMS production libraries are LLA controlled and updated at several slots a day, with an LLA update. I think that if your libraries can be updated each second/minute by each linkedit job that produces a new production module, this is a frequency which you don't want LLA to follow up on.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Monday, January 13, 2014 21:07 To: [email protected] Subject: Re: LLA/VLF -- NAMED LNKLST? Why would you hope that production libraries are not typically modified frequently? Our production application libraries are modified on a daily basis, with one or more business application programs updated daily as the business requires. Frank >________________________________ > From: Peter Relson <[email protected]> >To: [email protected] >Sent: Saturday, January 11, 2014 2:07 PM >Subject: Re: LLA/VLF -- NAMED LNKLST? > > >>you have the choice to either cache the directory or cache often used >>loadmodules or do both. So if you have a number of frequently modified >>members and a number of static and heavily used modules, you could get >>the best of both worlds by not caching the directory and caching >>frequently used load modules. > >Frequently modified production libraries is, I hope, somewhat atypical. >Nevertheless, I would have said >-- you can cache the directory or not >Regardless, you get caching of often-used modules. > >And if you're willing to participate, you can get the best of both >worlds by asking to cache the directory but notifying LLA when you have >updated members. Refreshing all of LLA could be done; updating the >entire library could be done. But both of those are overkill and will >negatively affect performance. Best is to use LLACOPY or MODIFY LLA to >update its information about the specific updated modules. > >Note that it is intentional that LLA does not attempt to track >automatically what has been updated and do something about it. Doing so >could potentially cause application failures due to mismatched levels >of modules. > >Peter Relson >z/OS Core Technology Design > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
