Re: Opt 21 Restore

In a re-read of what I had just posted, I realized two paragraphs are not explicit enough about _which_ command; only the command parameters were noted by name, as I had omitted the RSTLIB command name. My prior reply is posted again here, in its entirety, but with two addenda embedded inline.

On 07-Nov-2014 13:59 -0600, CRPence wrote:

On 07-Nov-2014 12:41 -0600, Steinmetz, Paul wrote:

I CPYSPLF the restore joblog to PF, then wrote a RLPLE program to
table and count all the various messages.

A better choice might be DSPJOBLOG OUTPUT(*OUTFILE) within the job
that performs [and just after] the Restore activity.

Result was a one page summary of the restore. I did this to insure
that I didn't miss a critical restore issue. After identifying the
critical errors, I scanned the joblog for the message in question,
for complete details of the error(s)

The next two quoted paragraphs refer to the RSTxxx [e.g. RSTLIB] commands for their OUTPUT() specifications; i.e. they are not making additional references to the DSPJOBLOG command output referred to in the above "A better choice..."

The OUTPUT(*OUTFILE) and OUTFILE() should, IIRC, provide [much of]
that same messaging information from the joblog. Some of the
messages that are merely previously-logged [likely many from
individual object-handlers] probably would not appear there, but all
effective "not restored" conditions should be logged there, plus
being identified conspicuously and distinctly from the non-failing
conditions.

Essentially, as output from the restore, the restore will log only messaging that the request itself exposes to the user. The output of the joblog itself, would provide all of the [non-deleted] messaging, and is why the DSPJOBLOG was noted first and as a suggestion in place of copying the joblog from a spooled file, because that feature supports writing externally-described output.

There is also OUTPUT(*PRINT) as I recall, but then the same potential
issues exists for effective screen-scraping used to parse the output
instead of simply querying a[n effectively relational] database file,
as exists for use\processing of the QPJOBLOG spooled output.

Below is sample from my Restore 21, which was a migration.

4/04/12 17:25:13 9406 550 to 8205 E6C MIGRATION SUMMARY
<<SNIP>>

I am unsure if the <snipped> output might have been
mis-copied\mis-pasted, but with just a cursory review, there seems
to be at least a couple lines of suspect results. Some examples:

• The following text appears extraneous and overlaying something:

"0.479096 QOSINIT QSYS 02D9 QMNSRBND QSYS 02B6 MSGID"

• The following text likely is what was improperly overlayed by the
above:

CPF9032 15037 Document interchange session not started.

• The following two messages do not correspond to an expected
first-level text:

CPI3210 16529 Receiver QSAJRN1050 in QUSRSYS saved while attached.

CPF9999 407 File WRUSGRP02L in ARCH88 shares access path.