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



That this was an upgrade from v5r2 to v5r4, so the restore was actually part of an upgrade scenario versus a standard DR, the origin of the problem in understanding this issue is probably now clear. It seems that the discussion is not about DR, but about an _upgrade_ that is performed with _data migration_ from a prior release. There are a variety of data migration strategies. When an upgrade is thrown in, the best choice is based on the capabilities of the hardware support for the release levels involved. Ideally the target system can be installed to the release level of the source system with only the LIC & OS, to which the restore-21 is performed, where the target is then upgraded from the lower to the higher release level; ideally, because that limits the number of release upgrades to just one.

The most common failure in such upgrades is for an *assumption* that it can be done simply by restoring stuff, rather than following a well understood and tested migration path. And for failure to follow the path with a good checklist, most typically the biggest problems are a direct result of improper migration of the user data in quasi-system user libraries, primarily QUSRSYS and QSYS2. As such my guess is, that rather than anything properly termed metadata being at issue, the issue is user data. Although it is called /user data/ because it was supplied by the user\operator to an application on the server, on another platform it might be called instead, /application data/; where in this case, the "application" is the OS.

Regards, Chuck

Ingvaldson, Scott wrote:
Additional information from John:

When BBACKUP was used, ENDSBS OPTION(*IMMED) preceeded BBACKUP. The
commands used by BBACKUP are:

SAVSYS DEV(TAP35) ENDOPT(*LEAVE) SAVLIB LIB(*NONSYS) DEV(TAP35)
ENDOPT(*LEAVE) ACCPTH(*YES)
SAVDLO DLO(*ALL) DEV(TAP35) ENDOPT(*LEAVE)
SAV DEV('/QSYS.LIB/TAP35.DEVD')
OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) ('/QNTC' *OMIT))
ENDOPT(*UNLOAD) UPDHST(*YES)

The SA attempted to restore from 820 (?) to 520. I was not present when he did this. All he offered was that the metadata was not saved by the above commands. I asked what was included in the metadata, and got no answer. When I showed him a page from
infocenter detailing the processes used by option 21, he stated
that *something* is different.

Stated that he had been on the phone with IBM for weeks.

Old box was v5r2 and new box is at v5r4. I have NO idea what was loaded on the new box.

All of this is to do DR planning at some point. He even stated that
option 21 was also non functional. But he quickly moved on. This makes absolutely no sense to me.

Does any of this help? Any additional information that I might be able to dig up that could be worthwhile?

Our mutual supervisor has asked me to contact IBM support for clarification. I would dearly like the call to be worthwhile. But, I already see that I am missing a considerable level of detail. For
starters, what did he do, on what kind of system.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.