Kees, why not? I've been at shops that have done it. You can update at the member level and a post link step with a program to do the LLA update is not a performance issue for the rest of the system.
LLA REFRESH or UPDATE of the entire loadlib each time is a different story. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Tue, 14 Jan 2014 11:39:27 -0800, Frank Swarbrick <[email protected]> wrote: >Oh!� I certainly didn't mean frequently throughout the day.� Just a few times >a day. >________________________________ > From: "Vernooij, CP - SPLXM" <[email protected]> >To: [email protected] >Sent: Tuesday, January 14, 2014 12:53 AM >Subject: Re: LLA/VLF -- NAMED LNKLST? > > >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 > > > >---------------------------------------------------------------------- >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
