On 15-Oct-2014 12:35 -0500, John Allen wrote:
I am trying to restore a couple of files from a save file.
The files were saved another system (not ours)
We are running 6.1
I can do a DSPSAVF file and see the contents of the save
file
I have tried doing the restore with QSECOFR
Then I created a user profile the same as the owner of the
files (display on DSPSAVF screen)
Creating the user profile that owns the object on media is required,
or the Allow Object Differences (ALWOBJDIF) specification of either *ALL
or *OWNER would be required, to allow the objects to restore without errors.
We do not use
Do not use ?what? Perhaps "do not use BRMS" was going to be
written\mentioned? Hmmm... reading further, seeing the same words,
presumably that is "do not use Group IDs". No matter about BRMS, if
that were the intent; because the issue is described below using native
Restore Object (RSTOBJ):
The error is:
RSTOBJ OBJ(*ALL) SAVLIB(QTEMP) DEV(*SAVF) SAVF(TGLIB/TGSAVF)
DTAARA DFWSAVDBX in library QTEMP restored with primary group *NONE.
The above is msg CPI380E. Note that a DSPJOBLOG OUTPUT(*PRINT) with
LOG(4 0 *SECLVL) filtering in place gives the fullest information;
including any replacement values included in second-level text, as well
as the context of the messaging.
For the simple object type *DTAARA [not the complex object type of
database *FILE for which the owning-component supplies an object-handler
to effect the /restore/ processing], the restore processing implicitly
resolves the inability to assign the object to have *no* Primary Group
(PGP); i.e. effectively having set the NEWPGP(*NONE) using the
equivalent of a Change Object Primary Group (CHGOBJPGM) request. The
database object handler appears not to be implementing the same
processing\effect.
Cannot transfer to new owner or primary group.
The above is the msg MCH1011 [LIC exception x/0A0B] which, according
to the next message, occurs at instruction x/104A of processing, and is
an unmonitored exception received by the Restore Pre-Processing [thus
issued T/QDBRSPRE]. The program QDBRSPRE effects the Create of the
database file, the setting of the owner and primary group, and
establishing the public authority such that when the members are created
soon after [into which the data will be loaded], those *MEM objects will
inherit the same owner and authorizations.
FWiW: same issue was documented in an old [not English] forum
discussion topic for v5r3 showing instruction x/0B2B instead.
Function check. MCH1011 unmonitored by QDBRSPRE at statement
*N, instruction X'104A'.
The above is a msg CPF9999, the Function Check (*FC). The failing
instruction however, is probably a CALLX to the program that assigns
database file ownership and PGP, not the actual Transfer Group Owner MI
instruction.
Cannot transfer to new owner or primary group.
Function check. MCH1011 unmonitored by QDBRSPRE at statement
*N, instruction X'104A'.
FILE DFWOUT not restored to QTEMP.
The above is any number of various possible messages with "identical"
first-level text; the message identifier is required to record a symptom
keyword. Somewhat moot to record that message however, as the prior
errors logged already sufficiently document the failure.
FILE DFWDFD not restored to QTEMP.
1 security or data format changes occurred.
The above is msg CPF3848 documenting the prior logged CPI380E for the
Data Area object.
1 objects restored. 2 not restored to QTEMP.
The above is msg CPF3773 issued as an Escape to diagnose that the
restore completed, but with previously logged "errors" that should be
reviewed.
F1=Help on Cannot transfer to new owner. (notice the "QSECOFR";
I was not signed on as QSECOFR when this error occurs
The MsgID was omitted; the following message is the subject msg MCH1011
Message . . . . : Cannot transfer to new owner or primary group.
Cause . . . . . : An attempt has been made to assign or transfer
the ownership or primary group of an object. QSECOFR can not
be the new owner or primary group because of reason
code X'0003'. The reason codes and and their meanings are:
<<SNIP>>
0003 - The profile for the new primary group does not
have a gid for transfer group owner.
The sensible presumption is that the user QSECOFR was assigned as the
PGP of the saved object(s); thus for which the msgMCH1011 transpired.
I have tried Allow object differences, still fails
The ALWOBJDIF would assist in this scenario, only if there were an
existing object for which the differences must be resolved\ignored.
That is because in the given scenario, the objects are _new_ [scratch
restore vs restore-over] such that there are no /differences/ of
consequence until after the file object is created, but the failure
occurs before a PGP ever gets assigned, and the create is effectively
backed-out; if the restore\create request had been able to assign the
NEWPGP(*NONE) [as\in a handler for the MCH1011 condition], then the
/difference/ between PGP(QSECOFR) and PGP(*NONE) would have been
something reported as an allowed difference and reported with the msg
CPF3848, as a side effect of the Database Restore feature manifesting
the MCH1011 as CPI380E. Instead, the database *FILE object can not be
created [via\for restore purposes] because the Transfer Group Owner MI
instruction failed to ever set a PGP.
I set the profile to Group Id = *GEN
I infer, given that did not enable a circumvention, that "the
profile" refers to the owner of the object on media [and the same UsrPrf
created to become owner on the target of the restore]?
, still fails (although we do not use Group Ids and I am not very
familiar with it
The user profile _doing the restore_ is not the user that requires
the Group ID Number (GID), nor is the user profile that _owns_ the saved
object. The *USRPRF that requires the GID is the user to which the
Primary Group Profile (PGP) is being assigned; i.e. the user QSECOFR,
which apparently was the Primary Group assigned to the file(s) when [and
on the system whence] the file(s) were saved.
The user profile QSECOFR is /special/ as I recall, with regard to
having a UID and\or GID. IIRC there was a KB article ages ago that
described how to effect setting the GID of QSECOFR. Or maybe a
procedure was [eventually] documented with the availability of the
Change User Profile UID Or GID (QSYCHGID) API, for which taking the
system to restricted state (end all subsystems) may be required for that
or perhaps other system-supplied user profile(s).?
Google did not turn up much
Any help would be greatly appreciated
The failure actually seems familiar [from when I worked on the DB
restore code]; both the part about QSECOFR not having a GID and the
Database Restore failing when the User Profile defined as the PGP of the
object does not have a GID on the target system.
I would have figured that, if that defect were seen in the past [as I
recall], then that code would have been corrected to operate in the same
manner as is seen with the *DTAARA object in the above scenario; i.e.
the MCH1011 is manifest as a CPI380E "&2 &1 in library &3 restored with
primary group *NONE." Perhaps an old APAR was closed UR1 [fixed in a
future release] because the situation is easily enough recovered [in
most cases] by a simple request to effect generating a GID for the named
user profile; e.g. Change User Profile: CHGUSRPRF GID(*GEN). I had no
luck finding an old APAR on the web; I did not visit the IBM
service\support site to search there.
The initial space created [CRTS MI instruction] would have had an
"initial owner specified", but for lack of an equivalent "initial
primary group owner" on that instruction, the failure is likely being
manifest in the QDBXFRFI processing [or whatever is the Change Object
Owner (CHGOBJOWN) processor for the database *FILE object]. Presumably
the error is just resignaled to the pre-processor, which would appear in
a Trace; a trace of the failed request would confirm that the lack of
exception handling is where I would expect [notably, not inline to the
QDBRSPRE].
A circumvention for the issue would appear to be possible using one
of the following scripted invocations; the last scripted command request
of each, is the Restore Object request that was failing in the given
scenario, but that request should no longer fail if preceded by the
request(s) shown:
RSTOBJ DFWSAVDBX QTEMP *SAVF *DTAARA SAVF(TGLIB/TGSAVF)
CHGOBJPGP QTEMP/DFWSAVDBX *DTAARA NEWPGP(QSECOFR) PGPAUT(*ALL)
DLTDTAARA QTEMP/DFWSAVDBX
RSTOBJ OBJ(*ALL) SAVLIB(QTEMP) DEV(*SAVF) SAVF(TGLIB/TGSAVF)
CALL QSYCHGID PARM(QSECOFR x'FFFFFFFF' x'FB65EBC0' x'0000000000000000')
/* repeat above, 3rd parm changed [eg. x'FB65EBC1'], if CPF22CE */
RSTOBJ OBJ(*ALL) SAVLIB(QTEMP) DEV(*SAVF) SAVF(TGLIB/TGSAVF)
midrange.com
