Re: CPF5090 happening with annoying frequency

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?