On 03-Nov-2014 10:51 -0600, Steinmetz, Paul wrote:
We simply QSYS/RMVDFRID DFRID(*ALL) to clear the error.
Before doing that the next time, save\obtain-a-copy of the file of
deferral data in QRECOVERY; review the data for each /library/ datum in
the row(s) representative of the object(s) for that library, minimally
to determine if the library name is corrupted there? If a library name
utilized in the STRJRNPF request for the deferred-restore had came from
corrupted data in that file, then the CPF9810 would be /correct/,
implying again, that the prior failed attempt [the CPF3294] is the
origin for the issue [and thus the later message and side effects are
just /noise/].
Another RSTLIBBRM of the same library works, recreates do not occur.
Of course the definition of /another RSTLIBBRM/ is quite open to
implication\interpretation; the same request repeated again, with no
other action except Remove Deferral Identifier (RMVDFRID) since the
error, would of course be a restore-over vs a scratch-restore of that
specific object [and possibly others]. Conspicuously, a scratch-restore
of the problematic object is a minimal requirement. If the restored
library did not exist prior to that RSTLIB with deferral-identifier,
then a recreate attempt needs to have effected a Delete Library (DLTLIB)
to have a minimally-similar recreation setup.
Are these always just RSTLIBBRM onto an LPAR where the libraries
being restore never exist? If the *LIB objects exist but they have been
cleared with Clear Library (CLRLIB), then can the procedure be changed
to either Delete Library (DLTLIB) first, or at least issue a Dump Object
(DMPOBJ) against each presumed-to-be-empty library before the restore
actions start? If dump objects are taken, then after any failed
restore, the dump of that library for which the failure then transpired
could be reviewed for latent information that might have given rise to
difficulties. If the DLTLIB is not effected, then along with DMPOBJ,
the DSPLIBD output is easier to review than what might be encoded in the
dump, so those might be taken additionally.
No files are being journaled for the library being restored from the
source LPAR.
Do the /number of member/ attributes and the actual count of members
[as presented by the number of records in outfile that represent a
specific\distinct member name], match between the DSPFD TYPE(*MBRLIST)
and and DSPFD TYPE(*MBR) performed with OUTPUT(*OUTFILE) on the system
from which the file was saved?
Does the particular file identified in the CPF3294 have a historical
'last journal' name [and qualified library name] attribute appear in
output of either the Display Object Description (DSPOBJD) for
DETAIL(*FULL) and\or the DSPFD?
We do about 100 to 200 RSTLIBRM on a monthly basis with no issue.
I've had this issue occur about 5 times within the last year.
I've never been able to do a recreate.
A re-create attempt likely could require that the
situation\environment appear as the near equivalent [as close as
possible] to what was the situation was prior to the /failing/ restore.
Note: I realize that was a successful restore, but as a restore with
errors, I will tend to refer to that as a /failure/.
So as noted, minimally the object that incorrectly was identified for
having been journaled on the source LPAR [or appear to require
journaling per implicit journal upon restore via QDFTJRN or STRJRNLIB]
must be scratch-restored in a re-create attempt, just as it was on the
failing request, and quite possibly the same situation must be achieved
for all the other objects that were scratch-restored in the failing
request; i.e. they also would need to be included as a scratch-restore
on the re-create attempt. Another thing to mimic would be to have
signed-off and then signon again, if that is what the job for failing
restore had done.
If the prior failures had all been either RSTLIBBRM as
scratch-restore of the *LIB and object or as restore-into an existing
library with all objects as\presumed-to-be scratch-restored, then maybe
the full restore to a totally different partition [perhaps in the IBM
lab] might recreate when using [a copy of] that media. If the original
scenario is a restore over the existing libraries, then a first-pass
restore could restore just the libraries [omitting all objects, e.g. by
type], then a new process mimicking the full restore; otherwise just the
full request onto a totally different LPAR might suffice to recreate.
If the first-pass restore is the full restore, then that might be tested
first, and [esp. if originally the process is to effect] the CLRLIB
requests could be performed in advance of a new process attempting the
full restore wherein the *LIB objects are already there.
FWiW: While the same PTF-level for QDBRSPRE remains, if the messaging
from the instruction x/17F2 is atypical, a debug break-point program
could be activated before the restores to try to /catch/ the CPF3294
being diagnosed, and possibly allowing some more debug\doc-collection
work to either improve the possibility to effect a recreate or better to
diagnose the origin. One benefit to the OPM, is that breakpoints can be
added to the programs easily via scripted [optionally compiled]
command\statements, no listing may be required to figure out where to
place the break, and the breakpoint can be automated [to collect docs]
or prompted for more doc collections performed interactively.
midrange.com
