We are moving from V5R4 to 7.1 onto a new P720. We have been advised
to do a restore in such a way that we clear each of our libraries on
the new P720 prior to restoring each of them again.
Again? Whose advice; according to what migration path documentation?
If clearing those directories of /QSYS.LIB is recommended, why not
also being advised to clear other [non-QSYS.LIB] directories?
As a migration, is this a side-by-side scenario whereby the two
systems were run\tested in conjunction; the v5r4 being production and
the v7r1 remaining in test until a switch-over? And the intention is to
update the new\target system from the old\source system with an
_additional_ restore rather than performing both the upgrade and the
restore [from the latest save]?
I cannot see the benefit of this, and I see problems in that we have
logicals and join logicals over physical files in different
There are /problems/ with cross-library dependencies [with regard to
(join) logical files] whether the libraries are cleared, deleted, or
pre-created; those /problems/ are pretty much the same whether the
libraries are cleared or not. I am not aware that effecting Clear
Library (CLRLIB) would be any better or worse than Delete Library
(DLTLIB) or both the DLTLIB and Create Library (CRTLIB) with regard to
LF and PF.
What is a potential issue is whether the scenario includes saving and
restoring the Private Authority (PVTAUT). That is because if private
authorities were not saved, then the private authorities have to come
from Restore Authorities (RSTAUT) after [presumably also a second]
Restore User Profile (RSTUSRPRF) of *ALL.
Any comments / suggestions, please....
Following the documented migration path that matches the specific
situation seems most appropriate; work went into producing those
instructions, sufficiently generically, to allow each type of migration
to be successful for every customer. My preference is [what I seem to
recall was called] an unload\reload migration, rather than performing a
side-by-side migration; the former path somewhat effectively exercises
the DR, although also including an upgrade along with the data
migration, whereas the latter is most effectively accomplished using a
feature that /mirrors/ the effects of work on the source system to the
target to keep them in-sync instead of a final\second restore.
One reason for /clear/ or /delete/ operations when the target is for
a side-by-side, is because anything /deleted/ on the source system would
remain on the target system; i.e. a restore would be additive, such that
if a Remove Member (RMVM) had been performed, that member restored
previously remains on the target instead of disappearing, *unless*
something like the CLRLIB had precluded that effect. However the _same
issue exists_ for more than just /objects/. Non-object /entries/ can
present the same _additive_ issue for which the target is not accurately
matching the source after the migration; e.g. an authority entry that
was removed from the source system, unless that removal operation is
/mirrored/ while operating side-by-side, an additive effect from the
restore\migration could [like with the database file member] have an
undesirable latent effect [with a latent authority /entry/ persisting on
the target system irrespective the work performed to effect the removal
from the source system].
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3Jemail@example.com
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3Jfirstname.lastname@example.org
Before posting, please take a moment to review the archives