Re: Backup - revisited

[John McKee <jmmckee@xxxxxxxxxxxxxx>]

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.