-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Steve Thompson
Sent: 27 November, 2014 18:37
To: [email protected]
Subject: Re: VLF caching
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?
Correct, with the remark, that LLA caches directories in ist private storage,
VLF is not involved here.
>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.
Incorrect,
1) CSVLLIX1/2 are LLA exits, where you and I can influence LLA's calculated
decision to stage a module to VLF or not. Also LLA statistics are presented to
the exits, which can be used to record them in SMF records.
2) VLF rejects nothing, it accepts everything that is staged. It manages the
VLF cache by trimming modules to make room for new ones. All VLF exploiters,
except LLA, simply push anything into their VLF cache. When needing an object,
it tries first if it is still in the VLF cache, of not they will know where to
get the object from disk (Clist, Catalog record, etc. etc.). For these VLF
caches, the VLF statistics provide a good measure about the effectiveness of
the size of the cache.
>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").
See above.
>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.
In contrast to other VLF exploiters, LLA has decided to fully control the VLF
cache, it knows how large it is, knows what is in there and how much room is
still left. If a new module qualifies for the VLF cache, LLA decides which
module has to make room for the new one and instructs VLF to delete it. That is
why you see many Adds and Deletes, but hardly no Trims in the VLF statistics
for the LLA cache. VLF hardly needs to make room in the cache by trimming,
because LLA ensures room by Deletes.
I use CSVLLA1/2 to write the LLA statistics to SMF and from them, I get the
number of modules fetches solved by LLA from its VLF cache and the number of
module fetches that had to be resolved from dasd, for each LLA managed library.
This gives me a perfect view of the effectiveness of the CSVLLA VLF cache.
This is a report about October 2014:
DSNAME LLAFPCT PGMFCNT LLAFCNT
IMSPRDA.PGMLIBA 99.58 90636 21480761
IMSPRDA.PGMLIBB 99.90 36873 36026806
SYS1.CEE.SCEERUN 99.47 228279 42527075
SYS1.CEE.SCEERUN2 72.84 1658 4447
SYS1.CSSLIB 98.33 11153 656649
SYS1.DCF.DCFLOAD 0.00 47 0
SYS1.DMS.CCUWLOAD 98.29 29500 1692618
SYS1.IOA.LOAD 99.39 145235 23826464
SYS1.LNKLIB 98.72 77 5921
SYS1.LNKLIB 98.60 388147 27294767
SYS1.LNKLIB.PDSE 72.33 885559 2315360
SYS1.MAINVIEW.BBLINK 85.23 11140 64261
SYS1.MIGLIB 93.26 4455 61662
SYS1.NTV61.CNMLINK 98.12 21232 1105426
SYS1.NTV61.SCNMLNKN 99.97 100 316186
SYS1.REXX.SFANLMD 0.00 10 0
SYS1.SAS.SETA.LIBRARY 98.91 227508 20597942
SYS1.SAS.SETB.LIBRARY 99.29 8787 1225716
SYS1.SA34.SINGMOD1 99.45 6682 1199285
SYS1.SA34.SINGMOD2 99.67 1907 575463
SYS1.SPF.LOAD 98.95 42 3961
SYS1.SPF.LOAD 98.66 140911 10366011
SYS1.SPF.UPDLIB 64.42 978 1771
SYS1.ZIP390.LOADLIB 96.70 1039 30460
Kees.
>Regards,
>Steve Thompson
----------------------------------------------------------------------
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
