Re: Backup - revisited

Chuck, your explanations are, as usual, extremely informative. I think I have a
partial answer after looking at the source you listed.

Specifically, there is one additional step following the SAV command. I am
curious as to what the following does:

SAVIASPS:
QSYS/CHGVAR VAR(&COMMAND) VALUE('SAVIASPS ')
QSYS/CHGVAR VAR(&NXTCMD) VALUE('NOMORE ')
CALL PGM(QSYS/QSRSAVIA) PARM(&DFT '*NONSYS' &CANCEL &DEV1 &DEV2 -
&DEV3 &DEV4)

A CL program is called, it has 430 statements. This may be the mystery meta
data from what I can get from just doing a quick glance.

John McKee



Quoting CRPence <CRPbottle@xxxxxxxxx>:

Mostly gibberish to me, except what IBM [apparently] said. But as
far as what GO SAVE option-21 does, you can see exactly what that is,
simply enough by performing a RTVCLSRC against the program that performs
that function; QMNSAVE, as previously noted by someone.

With regard to the reference to metadata and conversions, it is as
though someone familiar only with another platform, or a DBA, has been
describing the situation. For the upgrade on the target system, the
_data and objects_ that were saved from the source system and restored
to the target, would be converted either as part of the install\upgrade
or post-install to the new release. The metadata on i5/OS generally
means the attributes of the _objects_, since on the object-based i5/OS,
the objects and attributes define the encapsulated data; even though not
all object types may not be enabled for saving and restoring the data
within the object.

If the problem has been narrowed to an issue with a failure in
restoring data outside of /QSYS.LIB, then I would think that would be
the topic by itself. What exactly were the i5/OS error messages
produced during the failed restore request? Regardless of what backup
software was used, the checklists in the Backup & Recovery Guide still
apply, in how to properly recover a system; IIRC the /QNTC/* is omitted
[by SAV itself] because the network storage space would be saved by
other activity in the save-21 [and non-integrated servers are typically
backed up separately on their own hardware], but /QNTC the directory is
saved, and restored with special procedures for any integrated servers.

Is the issue that the /QNTC was not saved, and therefore would not
and could not have been restored? And that the existence of integrated
PC servers is impacted by some missing /QNTC information?

Regards, Chuck

John McKee wrote:

I received an email from the sa. The tone was somewhat more civilized
than in the meeting. He attached a document describing some issues.
I will paste some of it here, as this might make more sense to
others:

During this time a GO SAVE 21 had to be performed on the old hardware
to capture the data and necessary meta-data required to perform the
conversions.

A restore and conversion procedure was available on the new server
that read the meta-data and performed the necessary conversions.

The GO SAVE process does a lot more than just execute back up
commands.

Each time that I worked with IBM support the first thing they asked
was did you perform a GO SAVE 21.

IBM agreed we were executing all of the right commands using our SFHC
custom back up procedure, but was unable to give me a definitive
reason as to why I could not restore all of our IFS directories.

I remember working with IBM on a SAVE problem following the
application of PTFS. I ended up having to omit the /QNTC file system
to get it to work again. This was done with IBM's blessing. The GO
SAVE 21 procedure saves the /QNTC file system without a problem.
The QNTC file system is the windows server file system.

Does any of the above clarify anything??

John McKee

Quoting CRPence <CRPbottle@xxxxxxxxx>:

That this was an upgrade from v5r2 to v5r4, so the restore was
actually part of an upgrade scenario versus a standard DR <<SNIP>>

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