On 11/27/2014 02:22 AM, Vernooij, CP (ITOPT1) - KLM wrote:
<SNIPPAGE>
No, here I read a common misconception about LLA and VLF working.
LLA module caching and directory freeze are separate functions. Directories are
kept completely in LLA's private storage. Modules are cached in VLF.
LLA fetches only modules from the VLF cache if it knows it is still there,
hence the 100% VLF hitratio.
VLF does not do caching, VLF exploiters cache objects into the VLF cache (LLA,
TSO clist, Catalog etc.).
The '5 fetches' algorithme, together with some complex calculations about
memory use, cache efficiency etc. are done by LLA, to determine if a module is
going to be staged to VLF.
Kees.
<snip>
LLA is, as I understood it, caching the directory for each
managed PDS/PDSE (which is affected by FREEZE/NOFREEZE). Is that
an incorrect understanding?
The VLF, using its rules, either caches or rejects the cache
request -- there is the CSVLLIX2 exit which I know gets involved
with the CSVLLA class. And when that call is made, it is made
AFTER the "load" has been effected so that the requesting address
space is not held up. The CSVLLIX1 exit is PRIOR to the "LOAD"
being effected, and so the amount of work done in it can be
rather detrimental to the throughput of the whole system.
This indicates to me that VLF is very much involved in the
control of cache. If the weight assigned to the module, as you
pass through CSVLLIX2, prohibits caching, I believe it is VLF
that doesn't bother. After all, the trim code apparently is a VLF
module (I'm sorry, I can't remember if it is COFTRIM or VLFTRIM,
I only remember that TRIM is part of the name that STROBE
captured when we saw a COBOL program spending an inordinate
amount of time in "LOAD/LINK" "functions").
If my understanding is incorrect, I really would like to know --
because it means that I have greatly misinterpreted the stuff
I've read in various published manuals and other information
passed to me in trying to diagnose what I believe to have been
caused by too small of MAXVIRT for CSVLLA.
Regards,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
