× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Chuck,
Thank you for your very informative reply.
The error message makes more sense to me now.
Maybe some change to the message text could be made to
emphasize the relationship of >this< Level Identifier to save
date of the media ?
(Not entirely sure I stated the relationship as you explained)


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, August 11, 2014 2:56 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.