×
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 27-Oct-2014 11:29 -0500, Ted Breedon wrote:
I recently did a opt. 21 backup/restore to a different lpar and I
received the message "Message . . . . : 28 libraries restored; 1
partially restored; 0 not restored. " but I don't see anything
specifying what wasn't restored. When I look above and below the
exact entry of the message (MSGID CPF3779) I don't see anything
useful. What's the best way to figure this out?
The Output parameter on the Restore feature is nice, but prior to
that capability [and per this being after-the-fact], the joblog would be
reviewed for the origin [instead of reviewing for the similar data
either in a SPLF or in an OUTFILE]. Using the Display Spooled File
(DSPSPLF) of a spooled joblog of the restore [preferably a copy spooled
with LOG(4 0 *SECLVL) but other log levels are likely to include some of
what is necessary to find the basic\minimal origin details], the actual
restore Request Message can be positioned-to first and then the F14=Find
Options can be utilized to setup for F16=Find to locate the undesirable
effects that were logged as messages.
Rob suggested searching with the Find feature on "not restored" and
that might work typically, that search is open to translatable material
for which phrasing is a potential issue ["Unable to restore" could be
used instead], but also per lack of case-insensitive search of DSPSPLF
[obviously other tooling is available] the casing of the chosen wording
is also potentially problematic ["Not" is different from "not"]. What
has long been used for such searches is the language-specific token for
"Escape" [for exception message] or "Diagnostic" [for warning message],
along with the actual column positions limiting specifically to where
that formatted data must appear [e.g. in v5r3, columns 12 to 22 can be
searched for 'Escape' on a USEnglish spooled joblog].
As I recall almost any Escape message logged since the Request
message starting the Restore request up until the /partial restore/
Escape message about the result of the overall request, would be an
error that was directly responsible for the counts in "partially" and
"not" categories; about the only other Escape messages that could be
seen within that phase of processing would be in exit program [including
system request] processing or break handling programs, but the context
of any messaging [given minimally the from-program and to-program,
though the text likely also would be telling and] would clarify with
regard to relevance of that message to the restore. If there are no
Escape messages betwixt, then start over with the searching from the
beginning of the Restore request message, but use Find instead for
Diagnostic messages. FWiW the most likely origins will be diagnosed
with a message identifier prefix [message ranges] of one of the
following listed, but the individual /object handlers/ for restore [such
as Database restore or journal restore] might have their own messaging
that may not have an associated /restore-specific/ message logged; no
matter, guessing which message or msg pfx is best searched versus
searching for 'Escape' is likely a poor choice: CPD37, CPD38, CPF37, CPF38
midrange.com
