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

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.