Re: CPF5090 happening with annoying frequency

On 21-Jul-2014 16:01 -0500, James H. H. Lampert 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?

That was understood to be possible, even expected. But also understood to be possible that some programs might only read the underlying data and need not await completion of rebuild of unique access path(s). Also understood, was that programmers [should] know how to code to handle open and I\O exceptions. Not being able to predict when or even if a unique access path can be built, IBM thought best not to wait indefinitely nor even some fixed amount of time to timeout; instead an exception diagnoses the condition to allow the program(mer) to decide if and how long to await completion of the asynchronous task.

Both synchronous and unexpectedly long waits are, unsurprisingly, much more detested than errors diagnosing a condition for which the programmer can code a reactive behavior.

The capability exists to ensure access paths are included in backups and restored with recovery [B&R]; effect the save and restore feature in a manner to effect the proper restore with the saved access paths, and the issue with msg CPF5090 can be avoided.

Anybody have any suggestions on how to prevent this?

Save and restore with valid access paths, and restore in a manner for which access paths can and will be restored versus in a manner that requires the unique access path(s) to be rebuilt. Notably, the LF\LFM as /owner/ of the unique access path must be restored in the same Restore Library (RSTLIB) or Restore Object (RSTOBJ) [or equivalent API] request as the request that restores the data [in the underlying physical member(s)].