MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2014

Re: CPF5090 happening with annoying frequency



fixed

On 21-Jul-2014 16:44 -0500, Paul Nelson wrote:
James H. H. Lampert on Monday, July 21, 2014 4:01 PM wrote:

What in Heaven's name was IBM thinking?

I'm sure (even though I'm waiting for the box with the source to
IPL, before I can check the statement that's throwing it) this is
what I've already seen too many times before: a keyed PF (with or
without keyed logicals) not having its access path ready by the
time it was needed.

How could they possibly NOT expect that a program would be
restoring a file from a save file, then immediately repopulating
it?

Anybody have any suggestions on how to prevent this?

Aside from ensure save\restore includes the access paths, open the LFM(s) with the UNIQUE specification before opening the PFM with the data that needs to be maintained with a unique key. Or, define the UNIQUE on the physical instead of the logical; e.g. with a CONSTRAINT of type PRIMARY KEY or UNIQUE KEY.


Have you thought about submitting the restore and repopulate jobs
into a single-threaded job queue? That would let the access paths get
rebuilt before you start putting data into the files.

The access path rebuilds are *asynchronous* to the restore. That means, to ensure synchronous rebuild is *not* via a single-threaded job queue, but to *open* the LFM with the unique access path *before* opening the physical member over which the unique access path is built.

Also, I hope you're sorting the data into the proper sequence ahead
of time to reduce the thrashing associated with maintaining the index
area.

Huh?






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact