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.
midrange.com
