Re: V5R4 to 7.1

On 14-Oct-2014 17:16 -0500, John McKay wrote:

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

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