Frank, It was not said that explicitly, but 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. Statistics could predict your profits with this approach.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Friday, January 10, 2014 00:42 To: [email protected] Subject: Re: LLA/VLF -- NAMED LNKLST? Thanks Joel. I did understand that user did not mean a specific user (like myself). I was pondering if it would be useful for "production application" libraries, but it sounds like it would not be worth the disadvtanges, since we do update those frequently. Perhaps for IMS system libraries, though, it would. Thanks! Frank >________________________________ > From: Joel C. Ewing <[email protected]> >To: [email protected] >Sent: Thursday, January 9, 2014 2:21 PM >Subject: Re: LLA/VLF -- NAMED LNKLST? > > >If it is a highly used load library, access will be faster and physical >I/O to the library reduced if it is defined to LLA, because an >LLA-managed library has its directory cached in memory and a highly >used load module could itself become cached by the VLF address space. > >The disadvantages are >(1)the library will be allocated to LLA address space for the duration, >so it cannot be easily re-sized, moved, or reorganized; (2)members >Updated/added/deleted in the library will not be "seen" until and >LLA-refresh is done on the library to update the cached directory >information. This requires issuing a console command to z/OS, which is >typically beyond the authority of a non SysProg user. > >Although there are ways to work around these limitations, a load >library would have to have very significant activity to be worth the >effort. I doubt if Peter intended to imply this technique were likely >to be appropriate for a library belonging to or modified by an individual user. > >More commonly, non-LNKLST LLA-managed libraries would be high-use but >relatively stable load libraries belonging to the installation or to >major application subsystems (e.g., DB2, CICS) which are only needed by >selected address spaces instead of globally, but which may be subjected >to 1000's of load requests in a short time frame. From Peter's >viewpoint these would be "user" libraries since they are not owned by >z/OS but by applications that run under z/OS. > Joel C. Ewing > > >On 01/09/2014 02:11 PM, Frank Swarbrick wrote: >> I am in applications, not systems, so I don't understand all of this. Could >> someone briefly (and simplistically!) explain what advantages (and >> disadvantages) there might be in having a user lib managed by LLA? >> >> Thanks! >> Frank >> >> >>> ________________________________ >>> From: Peter Relson <[email protected]> >>> To: [email protected] >>> Sent: Thursday, January 9, 2014 5:38 AM >>> Subject: Re: LLA/VLF -- NAMED LNKLST? >>> >>> >>> I'm not sure what named lnklst has to do with user libraries in LLA. >>> >>> LNKLSTs are defined in "sets". Each "set" has a name. One "set" is >>> current. Others (previously "current") may still be active. The name >>> is the handle by which the set can be referred to in the SETPROG and >>> DISPLAY PROG commands and LNKLST statements within PROGxx. >>> >>> LLA manages all LNKLST data set by default. Any user load lib can be >>> added to LLA management whether it is in a LNKLST or not. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >... > >-- >Joel C. Ewing, Bentonville, AR [email protected] > >---------------------------------------------------------------------- >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
