Ed, Would it be possible to write small test drivers that run in multiple address spaces and concurrently access a PDS/E in (random generated) patterns similar to your product/site use? If such a thing could be built that would reliably reproduce the problem, then you could give it to IBM.
Of course, this would be painful, and perhaps not even possible. But if it were, then you would also have a fix/regression test. Kirk Wolf Dovetailed Technologies On Fri, Oct 28, 2011 at 11:50 AM, Edward Jaffe <[email protected]>wrote: > On 10/28/2011 4:53 AM, Jim Thomas wrote: > >> Has there been any isolation to environmental factors and or specific >> OEM utilities used ??. >> >> I presume that you do have dumps of the 0F4's ??. >> > > LOL! Of course! We've had hundreds of dumps. IBM analyzed some of them and > discovered that they are all virtually identical--the 0F4 is issued because > the PDSE is broken. The most recent detailed analysis showed that a > directory page of a PDSE contained member data. IBM cannot tell from the > after-the-fact 0F4 abend how it got that way. > > These PDSEs are larger than the largest allowable PDS and we do parallel > updates to them (something PDS simply cannot do) so there is no way to > replace this function with PDS. > > I speculate, for a smaller PDSE, that if you can always guarantee > externally serialized updates, as if the PDSE was a PDS (e.g., by using > DISP=OLD), you *might* be able to avoid this problem. But, that's just a > SWAG. It's not my code. > > > ---------------------------------------------------------------------- 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
