Chuck,
We simply QSYS/RMVDFRID DFRID(*ALL) to clear the error.
Another RSTLIBBRM of the same library works, recreates do not occur.
No files are being journaled for the library being restored from the source LPAR.
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.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, November 03, 2014 11:29 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RSTLIBBRM failed due to "false" DFRID
On 03-Nov-2014 08:59 -0600, Steinmetz, Paul wrote:
<<SNIP>>
Journaling is not active, but for unknown reasons, OS is requesting to
start journaling for this one object.
The saved object did not have journaling active, yet the restore seems to want to effect STRJRNPF.? Then perhaps the target library for the restore has a QDFTJRN *DTAARA, or has the effects of STRJRNLIB [¿visible on a request to Display Library Description (DSPLIBD)?].?
Ideally, a re-create scenario could be found. That could be as simple as scratch-restoring that object into the same library, into any library [including possibly QTEMP], or restoring the same or a similar group of objects [again into the same or possibly any library].
Does a restore of the same object(s) exhibit the same issue when restored to another system on which a> the library was created anew along with dependencies [including journals] b> the library object was restored previously [without the failing object(s)]? If so, then the problem should be reproducible from just the restore-side, even if the origin might lie in the save-side; but the conditions\attributes of the object saved on media should reveal why the failing code path was chosen on the restore-side. As such, sending a copy of the [data under that label of the] media should reproduce just the same, anywhere else; i.e.
in the lab.
Does the same restore of [just] that object give the same issue consistently; i.e. if just that object or that and all previously missing objects from before the restore were deleted, and then the restore were repeated, will the issue re-create? If so, then a debug-capable version of at least the QDBRSPRE could be used to reveal to the OS dev much about the details of the input for the failing [with msg CPF3294] Start Journal Physical File (STRJRNPF) request; from the description of the scenario, it seems, that is already anomalous processing because the file should not even have been targeted for the start of journaling.? While the later errors may be curious, if they are merely a cascade effect due to prior errors, then they are often not germane even if the path may be worth a review to reduce misleading side effects from any future incidents of prior defects in that restore path; i.e. there still may be value in the OS dev including those programs processing the deferred-restore as debug-capable if re-create is limited to that system.
Notice the "garbage" library name in the CPF9810 message.
The /garbage/ could be nothing more than the variable for the message replacement text, with uninitialized data; only because the effects are consistent with garbage-data makes the msg CPF9810 appear legitimately to be a problem with the library name passed on the failing STRJRNPF request.
The data could instead come from the data in the QRECOVERY/QADBRSDFRJ file; added\populated by the DB restore pre-processor to record the deferral of that object. The actual data [if referral data not yet removed] or the journal of that file [if the file is journaled] could be reviewed. If that file is not journaled, that could be helpful to obtain that information for a future failure [if the OS dev does not get an opportunity to work to resolve the issue by other action; such as a re-create with trace and\or debug].
<<SNIP>>
msg CPF3294 Information 40 11/01/14 01:02:09.793001
F/ QDBRSPRE QSYS x/17F2 T/ QDBRSPRE QSYS x/17F2
Message . . . . : Cannot start journaling for member *N.
Cause . . . . . : The start journal operation for a physical file
failed while restoring member *N file CRMB42010 in library BRCAUDIT.
Journaling will not be started for any of the members of the file
remaining to be restored.
Recovery . . . : See the previously listed messages. Correct any
errors, and try your request again.
Were there no prior messages listed for this file object? One would expect some condition much like the CPF9810 shown later; i.e. the failed request for the database restore pre-processor was an effective STRJRNPF, just like the later case [below] but in a deferral-restore, so one would expect the messaging to be consistent for the two invocations.
If nothing else, the code and message identifier could be changed to include data in some Message Data Fields Formats (FMT) to identify the qualified Journal (JRN) name; perhaps even here, the garbage-data would appear, implying the library name information was corrupted already.
The additional information about whence the indication for journaling was obtained by the QDBRSPRE would be helpful as well; e.g. from the object itself, from the library object, or from a data area. Such an enhancement would be helpful, but mostly only for the lack of the expected "previously listed messages"; again, something should be there.
msg CPF9810 Escape 40 11/01/14 01:26:42.054840
F/ QJOJRNPF QSYS x/0545 T/ QDBRSDFR QSYS *STMT
To module . . . . . . . . . : TM/ QDBRSDFR
To procedure . . . . . . . : TP/ RESTORE_DEFERRED_STRJRN
Statement . . . . . . . . . : stmt/ 8661 Message . . . . : Library
}ò X^ó¬¤ not found.
Cause . . . . . : The specified library does not exist, or the name of
the library is not spelled correctly. Recovery . . . : Correct the
spelling of the library name, or specify the name of an existing
library. Then try the request again.
Most likely the corrupted library name is the value passed to the STRJRNPF for the Journal (JRN) parameter; likely being a somewhat generic handler, the instruction that sent the message is likely to be unhelpful to ensure that, however a trace probably would. But if the issue can be re-created to be traced, then the issue could be re-created to have that program debugged; though again, this might be a latent effect, such that if the code had never been improperly invoked, then the code could not have logged these errors.
msg CPI9871 Information 20 11/01/14 01:26:42.055014
F/ QDBRSDFR QSYS *STMT T/ QSRRSDFR QSYS x/005D
From module . . . . . . . . : QDBRSDFR
From procedure . . . . . . : QDBGEN_SEND_PGM_MSG
Statement . . . . . . . . . : 6905
Message . . . . : Cannot start journaling for object CRMB42010.
Cause . . . . . : The start journal operation for the object failed
while restoring object CRMB42010 in library BRCAUDIT type *FILE.
Recovery . . . : If no other message indicates a problem with the
restore for object CRMB42010 in library BRCAUDIT type *FILE, then the
object can be used but journaling will not be done for the object.
See the previously listed messages for journal errors. Correct any
errors and try your request again.
This is generic, for any prior failure to effect the journaling for a deferred restore; not of any interest.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
