VLF (Virtual Lookaside Facility) is an OS/390 facility that stores objects and retrieves copies when requested. In a sense it is a server. LLA is a facility that improves module fetch time by storing the module pointer in VLF. Before MVS fetches a module from disk, it asks LLA (which, in turn asks VLF) if it has a copy of the module.
VLF keeps its objects in separate address spaces; these use expanded storage (if available) or central storage and are pageable. LLA is a client of the VLF service, and deals only with load modules. Other VLF clients deal with RACF profiles, and so forth.
Member COFVLFxx in PARMLIB contains a list of all the users of VLF. LLA is one such user. Member CSVLLAxx in PARMLIB contains a list of all libraries (and/or library members) that are managed by LLA. If this member does not exist, then all LNKLST libraries are managed by default (assuming that COFVLFxx contains a statement for the CSVLLA class, to enable LLA).
The MVS operator command D LLA will display all the libraries currently managed by LLA. The list it produces is rather long, and is best used with the SDSF log display. If you change a library (add or alter a member) that is managed by LLA, you should issue the MVS operator command F LLA,REFRESH to update the LLA information. Until you do this, the system (via LLA) will continue to use the old module.
VLF and LLA are perhaps not as well documented as a new system user would like, but more information can be found in the OS/390 Initialization and Tuning Guide. You can use LLA to make your programs load faster by adding your load module library to the LLA list. This makes sense if your program is (a) fetched hundreds of times each day, (b) is not in LPA, and (c) is not in LNKLST.
