Would it not make more sense to save on 5.3 user portion, restore on 6.1 version, test that you are stable, then upgrade immediately to 7.1 or 7.2?
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Thursday, April 28, 2016 10:15 AM
To: Midrange Systems Technical Discussion
Subject: Re: save and restore to do OS upgrade
Chuck is right. When you stay within the realm of a n-2 upgrade IBM has numerous conversion routines which run which reformat files and whatnot.
These probably go berserk when the format is outside of this.
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
From: CRPence <crpbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 04/28/2016 09:57 AM
Subject: Re: save and restore to do OS upgrade
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
On 28-Apr-2016 08:25 -0500, Rob Berendt wrote:
On 28-Apr-2016 08:03 -0500, Ketzes, Larry wrote:
I know how bad this is to do for about a hundred reasons, but I
want to know if it is even possible. I have a satellite office
that wants to perform a full save at 5.3 (don't ask), then restore
it to a 7.1 system. I was always under the impression that you
could skip one version but no more. So that they could go from
5.3, skip 5.4, and land on 6.1. But 7.1 does not jive with my
understanding of what is possible.
This is doable, and published.
Uh, No... Excepting when there is documentation of the specific path,
i.e. for a specific origin-release and specific target-release, and for
which there was specific software provided [esp. on the origin-release]
to assist in effecting that [typically unsupported] migration. So if
specifically-documented v5r3->v7r1 migration scenario exists, then
follow those instructions.
It is called a "migration" and not an "upgrade".
The published\supported migrations do *not support* the N+3 scenario
described by the OP, being migration from v5r3 to v7r1; i.e.
v5r3(+0)->v5r4(+1)->v6r1(+2)->v7r1(+3) is unsupported
The IBM i OS and LPP software are designed to support conversion only
from N-2 releases; they may by their nature be able to, in some cases,
effect conversion from earlier, but there is no intentional design nor
testing to ensure that is possible.
I would read the MTU (Memo To Users) for 5.4, 6.1 and 7.1.
Follow the steps at:
[
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzamc/rzamc1.htm]
Conspicuously, the only _supported_ migrations documented there [the
link above], are from v5r4->v7r1 and v6r1->v7r1 per the docs stating
that "This information describes how to migrate your data to IBM i 7.1
from IBM i 5.4 or later." By omitting mention o v5r3, that is an
unsupported release for effecting a migration using those procedures
presented in that documentation.
Caveat: I've never done this process for something more than two
releases back and their scenarios only cover that.
Good thing, because the consequences of attempting those procedures
on anything greater than N+2 can cause many subtle and blatant
failures\difficulties; issues that may persist but go unnoticed many
weeks or months into the future, and possibly even impact the ability to
perform successfully, a future upgrade.
I've normally only done this scenario for releases too old for newer
hardware but still not more than two releases back..
Wait for comments from others.
Biggest concern coming from pre-6.1 to 6.1-and-higher is object
conversion issues.
[
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_61/rzahc/rzahcwhatnew.htm
]
There should be ptf's for V5R3 to assist with this.
In the scenario of the OP, by restoring only user-data [and ensuring
not to restore any quasi-system\quasi-user data libraries; e.g. QUSRSYS,
QGPL, QSYS2, et al], the conversions [re-encapsulation\re-translation]
of their [and 3rd party] programs would likely be their biggest issue
for preparation.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
midrange.com
