Approach for Unicode Conversion and upgrade to EHP7

[sourabhchordiya]

Hi Experts,

We have a non-unicode ECC 6.0 ( base release) on DB400, we are planning to upgrade to EHP7,convert to unicode and migrate this to HANA. We need to perform this in minimum downtime, hence SUM with DMO option is best solution, however the source system is on iSeries and DMO with current version do not support this. Hence, we have arrived at an approach to perform non unicode upgrade to EHP7, then perform a heterogeneous system copy to HANA which will also include unicode conversion.

          Is this a valid approach ? If yes, can we perform the pre-unicode-conversion activities ( SPUMG,etc) before we start the downtime for EHP upgrade itself ? The source system is a single code page ( 1100 ) . Otherwise, if we upgrade to EHP7 and then perform pre-upgrade steps, we will need to do them in downtime which will result in an increased downtime and hence is not suitable.

Can you please advise on this ?

Regards,

Sourabh

[alichtenau]

Hi Sourabh,

unfortunately CU&UC and DMO procedure are not valid for your project. That's why your recommended approach is the only valid option. You have to perform two steps.

You can't process all Unicode preparation tasks before starting SUM. The EHP7 installation will bring new objects into your system which have to be processed as well as the objects from your source system. So if you finish your preparations and the upgrade then there is the source content processed, but the whole target content is not. So the Unicode Conversion will not run through properly.

But there are some steps which can be done on your source system while the Non-Unicode system is running productively:

1. Consistency Check for clusters (SDBI_CLUSTER_CHECK can run independently of a Unicode Conversion)
2. Reduce the data volume
3. Check for obsolet tables
4. Set the language flag
5. Run transaction UCCHECK to enable the customer coding for Unicode

Further information are provided in the respective Unicode Conversion guide (Steps are mentioned in the "planning phase" at the very beginning).

So you can run some steps before the upgrade and I would recommend to do that (to save some time in case you have to fix some errors/inconsistencies), but you have to run them again after the upgrade to ensure that the new objects have also been processed.

As many factors influence the runtimes it is very difficult to predict these for specific customers! Note #857081 gives a rough estimation.

Available Options for downtime optimization are:

• Hardware tuning (e.g. Additional CPUs, I/O Tuning...)
• Use additional (new) server for the Unicode system
• Database tuning (see note #936441)
• R3Load package split (see System Copy Guide)
• Table split (see note #952514)
• Migration Monitor (See note #784118)
• Distribution Monitor (See note #855772)
• Export: Unsorted export of transparent tables (see note #954268)
• Import: R3load option "Fastload" (See note #864861)
• Minimized Downtime Service (MDS) (See Note #693168)

Nevertheless a Test conversion will give you the best downtime estimation.

Cheers,
Andreas