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 <rel...@us.ibm.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> 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       jcew...@acm.org 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to