RE: GRTUSRPMN command not working

Are you offering to "sign on and just do it" ? :)

We do have access to these files from another machine at the
same release (V5R3)

Not so sure we have a back because we are not sure when they
became corrupted.


Allen

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Tuesday, December 04, 2007 3:38 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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