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

Reply via email to