×
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.
On 09-Apr-2014 16:30 -0500, gio.cot wrote:
I should perform programs and database migration from an IBM i with
v5r3m0 to a new with v7r1; could someone point out me which steps I
needs to perform this operation ? link or documents that can drive me
in this passage?
There is no supported passage, as an upgrade, from that old release
to that newer release. So indeed, the noted transition can only be
effected by a /migration/ of the programs and data to a new system.
Normally that is as simple as installing a system with the current
release [or getting a system pre-installed with that new release],
configuring that system, and then restoring only _user data_ [excluding
any quasi-system /user data/ stored in QUSRSYS, QGPL, and QSYS2].
However the IBM i 6.1 introduced a transition [similar to CISC to RISC]
whereby program instruction streams must be /re-translated/, so care
must be taken to ensure every program\executable can be restored, by
verifying the /observability/ of programs that would be restored to the
new system.
configurations SMTP or similar things can be brought in automatic
or is it necessary to rewrite by hand??
Because the OS provides support for an upgrade, only from as many as
two releases prior [i.e. upgrade from either N-1 (immediate prior)
release or N-2 (two prior) releases], the configurations must be done
manually; i.e. there is no automatic conversion support included in the
OS, to convert the v5r3 configurations\user-data into the equivalent IBM
i 7.1 configurations\user-data. Although some features may be unchanged
over the intervening releases, such that there are no conversions
required [thus a lack of conversions is not an issue], there is no
published list of what does or does not require a conversion to occur
for the dependent features to remain functional. So for example, even
if SMTP configurations could be migrated and the feature
perform\function as expected on the new system, other configurations
might not.
Ideally the v5r3 system could be upgraded to v5r4, and that would
enable a proper\supported upgrade to the N+2 release v7r1; i.e. an
install\upgrade path, even if to a different physical system, allows
restoring the older quasi-user-data against which supported conversion
processes exist to properly upgrade that [configuration] data to the
format recognizable\usable for the new-release; i.e. getting the
automated update to existing configuration data, thus avoiding the
manual configuration. Alternatively the new system may be able to be
scratch installed to have IBM i 6.1 onto which the v5r3 can be migrated
with a supported upgrade, and then another install\upgrade on that
system to the IBM i 7.1 to complete the process.
As an Amazon Associate we earn from qualifying purchases.