Re: RSTLIB OPTION(*NEW) overwrote existing files

Chuck,

The replaced conclusion came from the fact that
1) I didn't see any skipped messages in the joblog
2) I purged data from a handful of files, now it's back.

Actually, yes there was a prior restore that was canceled as the
system was running out of space. Thus the reason that I purged some
of the records from a handful of 1000+ files that had gotten restored
on the first go-round.

I could understand if canceling the restore damage one or even a
handful of files, which the system would have chosen to replace. But
as mentioned, the original restore completed for 1000+ files, none of
which were skipped on the second go-round.

We're on v5r4, and I believe reasonably current on PTFs...but I'll see
if I can find an APAR.

Charles

On Tue, Jul 12, 2011 at 11:14 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

  Was the effect of replaced\overwritten a conclusion based on the lack
of the "already exists" messages, the existence of messages\output
suggesting that the objects were restored\overwritten, or by review of
the object creation date, owner, restore date, and\or data?

  Had there been a prior restore of these libraries which had either
failed or otherwise been interrupted?  If so, the partially restored
object were actually "logically damaged", and database *FILE recovery
processing may have actually done the favor of destroying\deleting the
pending objects and recovery to allow the proper restore.  In the past
no such auto-recovery was supported for restore, such that a DLTLIB
would have been expected as user-invoked corrective, but the enhancement
for restoring logical dependencies may have had some impact on that
original design; though with not too much thinking, I think such a
change probably would be a defect.

What am I missing?

  If the results are as described, since there should be no other
parameter specification which should legitimately override that behavior
[that I am aware of or any I could imagine], then apparently what is
missing is a PTF [hopefully for an APAR with the HIPer designation].