Re: Backup - revisited -- MIDRANGE-L

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