× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.