Re: GRTUSRPMN command not working

One option. IBM ConsultLine should be able to assist to recover the situation.

I do know how to resolve it, but it would require a review for all of the relations, and best knowing or determining the origin of the error with the relationships. That is, it is best done by signing on and just doing it. I could write a program I suppose, but some things are easier done with human intervention. If you want to recover it yourself, then I can send a SAVF with the proper file definitions from the proper release; see the following:

However there is typically a shortcut, if there is a backup from the same release, taken prior to the improper restore activity; i.e. where the issue did not exist. Or given an /empty/ set of those files from a system which has no issue.
Note: Although these instructions might at least somewhat be generic for other database files in QUSRSYS, each set will have potential variances; i.e. Do *not* expect these instructions to be generically valid across any group of application files in the QUSRSYS library.

Optional historical information gathering:
DSPOBJD QUSRSYS/QAOSA* *FILE *FULL OUTPUT(*PRINT)
DSPOBJD QUSRSYS/QAOSA* *FILE *SERVICE OUTPUT(*PRINT)
DSPFD QUSRSYS/QAOSA* *ALL FILEATR(*PF) OUTPUT(*PRINT)
DSPFD QUSRSYS/QAOSA* *ALL FILEATR(*LF) OUTPUT(*PRINT)

Optional procedure to ensure backup before messup... err... mess with
SAVOBJ QAOSA* QUSRSYS *device *FILE UPDHST(*NO)

Recovery actions [please review; they are written up from thoughts, not from a prior write-up, nor from an actual test]:
Obtain a good copy of the DBF network QAOSA* in QUSRSYS; e.g. a save file with those objects taken from a system of the same release where there is no issue with the relationships
WRKF QUSRSYS/QAOSA* LF
4=Delete for all in the list
DSPFD QUSRSYS/QAOSA* *MBRLIST FILEATR(*PF)
RMVM QUSRSYS/QAOSAxxxx zzzz /* For each xxxx whose zzzz is empty */
RNMM QUSRSYS/QAOSAxxxx QAOSAyyyy QAOSAxxxx /* For each xxxx, where yyyy <> xxxx; i.e. rename the one member to match the file. Note: If there is more than one member with data.... here it gets tricky, so figure on which looks correct, and rename it to match the file name, and make a backup of the others before RMVM those */
RMVM any backed-up /extra/ members; those with data, that are not named same as the file.
MOVOBJ QUSRSYS/QAOSA* *FILE QUSRTEMP /* generic not allowed; means to suggest, repeat for each PF remaining in QUSRSYS by prefix QAOSA */
RSTOBJ QAOSA* QUSRSYS *devname *FILE OPTION(*NEW) MBROPT(*ALL) /* If errors here, something probably awry; if required, ALWOBJDIF(*ALL), but *never* when files already exist by the name on media! That is what is the origin for the issue, as diagnosed by CPI320A & CPI320B */
CPYF QUSRTEMP/QAOSAxxxx QUSRSYS/QAOSAxxxx FROMMBR(*FIRST) TOMBR(*FIRST) MBROPT(*REPLACE) FROMRCD(1) TORCD(*END) /* If error due to format mismatch... Eeek! Well, if so, then repeat this CPYF request with FMTOPT(*MAP *DROP) as an additional parameter specification */

Regards, Chuck