Re: Restore from LPAR1 to LPAR2

On 11-Aug-2014 11:41 -0500, Gary Thompson wrote:

I saved FILEA on LPAR1 to a save file on LPAR1 which I then shipped
to LPAR2.
Both LPAR show V7R1M0 on Display Installed Lic. Pgm.
When I attempt to restore FILEA from the save file I get:
CPF3283 - Saved file or member level ID not same as file FILEA.
FILEA is MAXMBRS *NOMAX with 1 member.
DSPFFD shows 49E5C8016C0CE on LPAR1 and 2
I'm sure I can restore after deleting FILEA from LPAR2, but: What am
I missing ?

Both the Member Level Identifier and File Level Identifier are 13-byte /creation date/ values [often described as having format CYYMMDDHHMMSS], having only decimal digit values. The Display File Field Descriptions (DSPFFD) shows Record Format information, thus shows only a Level Identifier of RcdFmt objects; the RcdFmt LvlId is a hash that includes hex digits that are in no way related to a date\time value. The Mbr and DBF Level Identifiers are visible with Display File Description (DSPFD).

An early sanity check in Database restore is to check if the date\time value of the file and member(s) are identical on media [the saved file.mbr] to each file.mbr of the same name on disk in the library into which they are being restored, *unless* the Allow Object Differences (ALWOBJDIF) parameters asks to override that behavior. The DB restore feature has always aimed to prevent accidental overwriting of data, so the default action is to prevent restoring data from a file member on media, into a member that has a mismatched creation date\time [aka Level Id]; not definitive, but the test is helpful as a preventive to data loss. The restore request must explicitly ask the DB restore to allow the overwrite of the data, or to request that the database restore should rename the existing file or member(s) [as an effective backup, allowing a restore requester to check which of the newly restored data or the data in the renamed object(s) should be the data on disk]. With neither an override to ignore the mismatch, or to force renames to prevent a mismatch, the restore fails with the msg CPF3283.

The *ALL special value on the ALWOBJDIF() parameter is the request of the DB restore feature to effect rename [RNMOBJ of *FILE, RNMM of *MEM] of the existing object to prevent data loss on a mismatch. The use of the *FILELVL special value [or *COMPATIBLE which includes the effect of the *FILELVL override] is the request of the DB restore feature to effect the overwrite of the data in the member(s) irrespective any mismatch in the level identifiers between media and disk.