Re: Transferring DCM Store

On 22-Jun-2017 07:32 -0600, Rich Loeber wrote:

While moving the security environment to a new Power 8 server
running 7.2 (from 6.1), the certificates do not show up on the new
box. In the joblog, it indicates that system file QAYDOBACK was not
restored because of a differing file level.

With regard only to what was [presumably, per unstated,] the error msg CPF3283 "Saved file or member level ID not same as file &1.":

• Restoring the so-called "user data" for a quasi-system database file [member], from a previous release is not a valid/supported means to "migrate" the data; the proper method is to scratch-restore the down-level file, and then *install* the feature [e.g. install QUSRSYS].

• Given the [member] data can be transported as-is to effect proper operation, then provide a special value specification that is inclusive of the *FILELVL capability on the Allow Object Differences (ALWOBJDIF) parameter of the Restore Object (RSTOBJ) request,

I have manually checked the file level for both the source and
target files and they appear to match.

Per Display File Description (DSPFD) output? Was that by review of the Record Format Level Identifier, or the File Level Identifier? A mismatch in the former would fail the restore irrespective the parameter specifications on the restore request, whereas a mismatch in the latter can be overridden with the specification of [, inclusive of; i.e. *ALL encompasses] the *FILELVL capability on the Allow Object Differences (ALWOBJDIF) parameter of the Restore Object (RSTOBJ) or Restore Library (RSTLIB) command.

I could just manually copy the three members in this file over to
the new box, but I don't want to shoot myself in the foot.

I am unaware if there was any conversion program(s) between the levels of IBM i 6.1 and IBM i 7.2 [could have included a conversion to IBM i 7.1] for which the data in a member of that file had required modification(s) and thus for which a direct "copy" of the data could end up being invalid. Note that the symptoms for an improper migration could be as conspicuous as an error when using the feature that depends on the data, or the symptoms could be subtle, with effects such as confusing [and difficult to diagnose] errors or incorrect output that could go unnoticed initially or indefinitely.

Has anyone run into this before?

Had the v6r1 system been properly migrated to the v7r2 system, having followed the documented migration path, then such features [with user data in a quasi-user system library] should have been operational as a side effect of the install process; i.e. as an effect of a supported upgrade, from either a release N-2 or release N-1 level of the OS.

Rather than taking a chance that the file data can be copied or restored, as-is, re-importing the data [via the interface provided for the feature] could be the most opportune.