>I know there has been plenty of previous discussion on this topic. However, I >couldn't find a simple answer to what I'm after. >We have a relatively small number of large PDSE's (25-30K members) that take >inordinately long to bring up member lists for (PDF 3.4) - ~20 seconds or more >on the first go-round. Timing drops to 3-4 seconds on subsequent accesses in >same session. >Is there anything simple in terms of blocking, allocation (primary vs >secondary), etc. that would impact performance and could be easily tuned?
Contrary to what Alan Starr said, my answer is a simple and definite NO. Here's why: Bringing up the ISPF 3.4 screen for the first time means that basically the complete PDSE is read. The directory is spread out, and I assume that the next 'directory entry' (or rather, the next 4K block containing directory information) can only be found by reading the predecessor. In my case (10K member that are all large) it takes more than 10000 IO's per dataset to get the first 3.4 screen. That time is basically IO time, and I wait around 90seconds. Your members appear to be smaller than mine, so you don't wait as long. BUFFER_BEYOND_CLOSE is useless. We do have it on, both for SMSPDSE1 and SMSPDSE. Our directory caching is set to take the default of 2G (come on, how large can a *directory* be ?!? ), and it does NOT cache entries. Unless I have my small 'keep-it-open' program running, in my case the second ISPF 3.4 takes as long as the first. And as Alan said, even my program only helps for the first less than 15 minutes, per system. I also *assume* (but don't know how to verify that) that in our case the 2G directory cache is severely insufficient, as I think PDSE keeps the whole 4K block (where *something* small is directory information) in that cache. Considering that we have about 10 of those beasties, all in the 5500-6000cyl range, not even a maximum of 16GB cache would help us, not to mention that 16GB of virtual storage actually *used* would cause an inordinate amount of paging (and in our case, DFSORTs usage of 6GB for sort jobs lets us hit the 30% warning threshold that health checker screams about). But your enquiry came at a very opportune time, as I am finally getting a discussion with the PDSE developers next week to discuss and address this exact same problem, bypassing the usual ETR and the 'please put on all available maintenance' crap. So stay tuned. And if others have the same problem, please speak up, as that will give me ammunition in that talk. I suspect that solving this performance issue will require a major design change on PDSEs part. Best regards, Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
