Barbara, I'm not trying to teach you how to suck eggs. I know you've had this problem for a few years now.
> > >I would not expect caching to help unless the member was already opened, or > >it had been used less than 15 minutes ago. > When I talk about 'caching', I don't mean hardware chaching (you remember > that I don't *do* hardware :-) ). I talk about LLA/VLF caching and the > SMSPDSE/1 address space(s), which are supposed to keep the directory > information around, even after closing. > PDSE_BUFFER_BEYOND_CLOSE(YES) > PDSE1_BUFFER_BEYOND_CLOSE(YES) > Which are turned on everywhere here. Which doesn't help *at all*. That is what I am talking about. The beyond close values are 15 minutes. If the member is not opened after that it is discarded from PDSDE cache. Your finding that it does not work. Peter Relson mentioned last September on this forum that LLA Freeze does not operate for PDSE that are non-loadlibs, so LLA and VLF will not be providing any benefit for PDSE. If the PDS version are in LLA/VLF then that is an advantage over PDSE. > > > Fault Analyzer gets invoked via RTM and LE exits in every address space in the > system. So while running in any address space, FA opens its parmlib and > checks where to look for the 'side files' - these PDSEs. *Then* Fault Analyzer > does the open and the directory reads, searching for the source code > information that has the matching timestamp to the abending (LE) program. I > have no influence whatsoever on *how* this is opened and/or searched. I get it. There's no JCL or facility to add buffering. > > Even under ISPF 3.4, it takes a minute or longer just to present the first > screen of directory information, of *one* of those big PDSEs. FA has a timeout > limit for real-time analysis of 10 minutes, and we hit that limit repeatedly, > especially when the lpar is cpu constrained. > > In the past, I had written a program that got started at IPL and only went and > issued a simple open macro against these PDSEs, then went into a > neverending wait, never closing the data sets. *That* had speeded up finding > the directory entries. (3.4 took 2 seconds or less.) And > BUFFER_BEYOND_CLOSE was *supposed* to keep the 'connection' (or > something) around for any PDSE opened, the connection being kept in the > smspdse/1 address space. It obviously doesn't work. The PDSE design as I > understand it still throws away all awareness of that dataset having been > opened before, the microsecond the close is issued against it, desoute how > the parm is set. It doesn't even keep it around for 15 minutes (or less). I understood that buffer beyond close related to caching of members, and not the directory. However the manual does say Directory and Member. Your sleeper program confirms there is some directory caching occurring while the file is open. I'm interested to know what do you have specified for the two HiperSpace sizes, Directory Storage, and what is the MSR value for the STORCLAS of this PDSE? > > Unless we're missing some parm that will fix this, I think I'll better revert > to my > little 'open program'. So my rant at least has shown me to use my homegrown > solution again. That sounds like a good idea. Earlier you mentioned storage cache. Have you looked at the SMF Type 42_6 records for the PDS-E to see where the IO is spending it's time? It sounds to me like a fragmented directory in this PDS-E could be causing some cache-defeating skip IO. The SMF record could give some guidance on whether you can benefit from loading the PDS-E into cache with HDS Cache Residency Manager(CRM) or EMC Permacache. I don't recall what storage you have, but if it is HDS then CRM and the Host software are included with the basic product. The Type 14/15 records also have actual PDSE buffer usage statistics. This would at least tell you if PDSE buffering is doing anything. Ron ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html