And I should have added: since LLA knows what is in the VLF cache, it will only retrieve a module from VLF that is there and this will give a near 100% VLF hitratio. So this VLF statistic is useless, because it is made 100% by LLA.
Kees. -----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
