Re: RSTLIB OPTION(*NEW) overwrote existing files

On 13-Jul-2011 05:13 , Charles Wilt wrote:

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

That surely would seem to imply that [both the save\restore component pre-processor and] the database pre-processor did not find the *FILE objects. The QSRRSPRE I believe performs the test for existing *FILE objects for OPTION(*NEW) processing just as with any other object types [and would diagnose each with a message], and then passes the since pared-down list of database files [only those which really are *NEW] to the database pre-processor QDBRSPRE. That database restore program should then attempt to create the files being restored; though possibly since they would appear to be "create for restore", perhaps that is just ignored, versus the CPF3201 "file already exists" and CPF3205 "file not created".? Or I wonder if the deferred [dependency] restore design changes had the SR pre-processor defer the processing of files to the database for those *FILE that exist but which are pending action "under database recovery"; that perhaps for lack of consideration for this new possibility, the database just plows ahead without regard to the OPTION(*NEW)?

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.

Was that restore also *NEW; or effectively, such that the library did not exist yet? Was the purge performed against objects which had failed to properly restore? If there was an error related to machine storage which terminated the restore, the errors should have included very specifically as recovery to *delete* any objects from that restore; that the objects were damaged.... regardless that the "damage" flag may not be set, since the damage is "logical damage" versus physical damage which is "partial" for data and "hard" for objects.

Was an pwrdwn\IPL performed since the original

I could understand if canceling the restore damaged 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.

A "restore descriptor" can hold thousands of objects. The descriptor being actively restored and canceled for restore-new versus restore-over will have very different effects. A partially restored file which never received "post processing", which is the case for either of a machine storage or user profile storage exceeded condition, can just have the data just "disappear" when a reclaim instruction runs [RTVDSKINF does this too, not just RCLSTG]. That is why the errors issued from restore after those conditions warn to delete them. A DSPFD against that library for all database *FILE objects has the potential capability to effect database restore post-processing, but that is something that I could not test.

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

Given a very explicitly detailed history of exactly what transpired and when, along with some accompanying joblogs and history details I could probably suggest if the outcome might be a generally FUBAR scenario which cascaded from an initial failure to resolve an earlier condition. There might be no specific defect, as the files assumed to be there really either might not have been [doubtful, though potentially an IPL or RCLSTG might have rid of them; some CPF3200 range messages hopefully logging in SCPF and\or history for the former, but with little fanfare if by reclaim], or might correctly have been considered already partially restored and thus allowed to be restored-over to "complete" the prior [same] operation which was still "pending" as tracked by database recovery [if so, hopefully QHST and\or restore job log would show some CPF3200 range "file recovered" messages]. Perhaps contacting IBM with that information for a PMR to investigate the scenario; they would probably also want VLogs.

FWiW a request to DMPSYSOBJ QDBDBDROBJ* TheLibName 19 D4 would log the existence of any pending recovery not yet effected; i.e. list the *DBRCV [database recovery] objects associated with any database *FILE objects. After DSPFD another dump request could verify if any remain; I am not confident that "restore post" processing completes all the work necessary to prevent the "disappearance" condition for dataspace objects, so I would only trust a completed restore [over] if the files from an original failed restore-new had terminated due to a storage exhausted condition.

Regards, Chuck