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