VLF doesn't do anything by itself. It will cache objects handed to it by the managers of those objects, like LLA, TSO CLIST processor, CAS address space etc. Which VLFCLASS should I specify for this case?
LLA can cache the directory of non-Loadmodule PDSes, this could help, like PDSEs directory caching will. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Staller, Allan Sent: 28 April, 2016 14:57 To: [email protected] Subject: Re: PDS I/O Performance Improvement <snip> It is a parmlib, I don't think the members will be staged to VLF (who would stage them)? Considering the I/O times and the size of the directory, I suppose the directory is the problem. Maybe LLA member caching might help if a BLDL is done to locate a member. Otherwise converting it to PDSE would help with its member caching. </snip> Just tell VLF to do the caching. It will handle it. However, VLF will most likely be limited in its effectiveness, due to the fact this is a parmlib, not a loadlib. Without getting too exotic, I would try (in order): LLA management of the PDS (same as VLF. Just tell LLA to manage it). PDSE <snip> > I'm looking for some suggestions on how to possibly improve I/O > performance to a PDS. A user is running a job that is reading a large > parmlib (through PROJCL I believe). I think the access is random > rather than sequential. The parmlib has ~180,000 members is has an > LRECL of 80/BLKSIZE of 27,920. The performance team has reviewed a > found ~ 6ms response time to the volume that houses the PDS with most > of the time being connect time. </snip> My guess is that this is PDS directory search. Do some googling for the historical performance problems with PDS directory searches. The CCW commands used were SEARCH KEY EQUAL (don't have the hex value handy). Reducing the number of members in the PDS will most likely help. Compressing the PDS *might* help. HTH, This email � including attachments � may contain confidential information. If you are not the intended recipient, do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message. ---------------------------------------------------------------------- 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
