Discussion:
V5R4 to 7.1
(too old to reply)
John McKay
2014-10-14 22:16:35 UTC
Permalink
Raw Message
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. 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.

Any comments / suggestions, please....

Regards,
John McKay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Alan Campin
2014-10-14 22:38:26 UTC
Permalink
Raw Message
I would suspicion that what they are doing is to deal with the logicals.

The first load loads the physicals and most of the logicals except where
they might be across a different library that was not loaded yet.

The second pass then reloads but this time all the physicals are already
loaded so all logicals will get loaded.

Anyway, that would be my guess. Someone might have another suggestion or as
usual, tell me I am full of it.
Post by John McKay
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. 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.
Any comments / suggestions, please....
Regards,
John McKay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Evan Harris
2014-10-14 22:44:46 UTC
Permalink
Raw Message
Hi John

As a general rule it's my preference to clear a library before restoring
over the top of it as it just makes things a little tidier, and it is
simpler to check that the restore has completed successfully.

Alan's comment may have something to do with their reasoning, though V7R1
is a lot more forgiving and smarter about restoring logicals across
libraries and similar situations.

If you are journaling make sure the journals are restored before you start
restoring the files using them.
Post by John McKay
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. 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.
Any comments / suggestions, please....
Regards,
John McKay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
DrFranken
2014-10-14 23:03:03 UTC
Permalink
Raw Message
Post i 5.4 the issue gets better but a save from 5.4 generally has the
issue of cross library logicals but it's worse when the Logical is in a
library alphabetically ahead of the library with the Physical.

Clearing the libraries: Good. Deleting them: Better BUT leaves you open
to issues with library lists that require those libraries.

Also be sure to save and to restore the libraries all in one command or
you leave yourself open to having to rebuild access paths even if you
said to save them.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
Post by Evan Harris
Hi John
As a general rule it's my preference to clear a library before restoring
over the top of it as it just makes things a little tidier, and it is
simpler to check that the restore has completed successfully.
Alan's comment may have something to do with their reasoning, though V7R1
is a lot more forgiving and smarter about restoring logicals across
libraries and similar situations.
If you are journaling make sure the journals are restored before you start
restoring the files using them.
Post by John McKay
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. 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.
Any comments / suggestions, please....
Regards,
John McKay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
CRPence
2014-10-14 23:31:25 UTC
Permalink
Raw Message
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].
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Steinmetz, Paul
2014-10-15 00:42:43 UTC
Permalink
Raw Message
John,

I did a migration a few years back from a P5 9406-550 to a P7 8205-E6C 740.
Save21 / Restore 21.
We ran twice, once for a test, 2nd time live, clearing user libraries, then restore.
We also had many x-lib LF.
Starting with V6R1, Defer ID handled the x-lib lf.

I would not upgrade OS and migrate to new hardware in a one step process.
Can you upgrade your OS first, either to V6R1, or V7R1?

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of CRPence
Sent: Tuesday, October 14, 2014 7:31 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Re: V5R4 to 7.1
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 f
rom the source system].

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-15 11:18:59 UTC
Permalink
Raw Message
Why stop at 7.1? Look at how long it took you to upgrade from V5R4. Why
not at least go to the most current OS? It's been out long enough for a
few cumes and even resaves.

I am guessing that your source system is so old that it can't have the OS
upgraded on it, right?
"New" P720? Which one of these is that?
http://www-01.ibm.com/support/docview.wss?uid=ssm1platformibmi


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Essinger
2014-10-14 23:56:53 UTC
Permalink
Raw Message
John,

Once a week when I restore my production libraries to the test partition, I
clear all the affected test libraries of all objects. I created a CL
program to do the clear, as dependent logical files are a problem. Monitor
for failures to clear the library and deal with any dependent logical files
that have caused an issue.

Once the libraries are clear, I turn around and restore all the libraries
with one RSTLIB command using the DFRID option. This allows for some
dependent logical files to be deferred until all the physical files are in
place. After the RSTLIB completes I then issue the RSTDFROBJ command to
have the system finish building those deferred objects.

Really slick way IBM has made this much easier at 7.1.

HTH

Jim Essinger
Western Power Sports
Boise ID
Post by John McKay
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. 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.
Any comments / suggestions, please....
Regards,
John McKay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Loading...