<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
