Search key equal can be a multi-track search, which even in a cached situation takes time. All PDS directory blocks are 256 bytes and a search for a member in a PDS always starts at the beginning of the directory. My guess is you would be better off with multiple proclibs and putting a JCLLIB card in the job for the appropriate proclib.
Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Thursday, April 28, 2016 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ________________________________ ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
