Re: Restoring an individual member into a source PF

Addendum:

Using OPTION(*OLD) effects failure when the expected-to-exist file does not. This is nice to have, to reinforce a presumption that the file will be there, over which the restore is being effected; thus why that specification is probably better for the given scenario. Although *NEW has an inverse effect, still giving an error as reinforcement of presumption, that is not applicable in the given scenario.

CPI320C [I think it is,] would be issued instead for use of the *ALL on ALWOBJDIF(), if the member level identifier was the issue for mismatch. That is, if the file level identifier had been concluded as matching [being the same] file between media and disk, yet the member on media was identified as not being /the same/ as the member on disk, then the existing member would have been renamed instead of the existing *FILE.

MBROPT() like OPTION() can also request *OLD or *NEW [scenario was using *ALL], similarly forcing an error for the condition whereby the presumption of [non]existence for the member on disk is not met. Presumably in the given example, MBROPT(*NEW) was desired.?

The *OLD options indicate the desire is to /restore over/ the object\data. That database *FILE objects and member\data are deemed necessary to better protect from accidental overlay is the origin for differences effecting the underlying RNMOBJ or RNMM to prevent data loss. The *FILELVL feature added to ALWOBJDIF() parameter enabled more cases of data overly possibilities; that option asks the database restore feature to ignore both file and member level identifier differences [between what is on the media and on disk], to go ahead and overlay existing object\data.

Regards, Chuck

CRPence wrote:

James H. H. Lampert wrote:

Is there a way to restore individual members into an
existing source PF?

When I tried it with

RSTOBJ OBJ(FOO) SAVLIB(FROBOZZ)DEV(*SAVF)
SAVF(BASESOURCE) FILEMBR((FOO (BAR)))
MBROPT(*ALL) ALWOBJDIF(*ALL) RSTLIB(FLATHEAD)

it threw a CPI320A exception, and I ended up with the
existing FLATHEAD/FOO renamed to FLATHEAD/FOO0001,
and a new FLATHEAD/FOO created, containing only BAR.

To be clear, CPI320A is informational only. It indicates the
original data is being protected, because the existing\old file
on disk, is not the /identical/ copy of that named file on the
media.

Given the formats are the same, ALWOBJDIF(*FILELVL) will suffice.
Also to match the expectation that FROBOZZ in FLATHEAD already
exists, the OPTION(*OLD) should really be added to the RSTOBJ
request. The ALWOBJDIF(*ALL) is best _always avoided_ when
restoring any database files; i.e. list every available [non
single-value] special value separately on the ALWOBJDIF()
parameter if desired, but avoid almost always the use of the
single value *ALL.