SAP on IBM i – Update week 24: In-place Code Page Conversion on IBM i is available for SAP release 7.30 and higher now
We would like to inform you about the latest improvements of the In-place Code Page Conversion (In-place CPC) procedure on IBM i.
As you may know already, the In-place CPC on IBM i offers SAP systems using a single Latin-1 code page a special way to convert an ASCII SAP sytem to an Unicode SAP system (SAP Note 800791 – Code Page Conversion ASCII to Unicode). The In-place CPC is based on the generic SAP Conversion of Single Code Page Sytems to Unicode (SAP Note 1051576).
In the past, the In-place CPC for the SAP system releases 7.0 to 7.03 was done using the installer tool SAPinst/TMKSVR. Starting with SAP SLToolset 1.0 SP13, the In-place CPC is using the SAP Software Provisiong Manager 1.0 SP08 (SWPM) and higher. In addition, the SAP system releases 7.30 and higher are supported now too.
As before the SAP Note 800791 is the starting point to prepare an In-place CPC. The document “Code Page Conversion ASCII to Unicode Version” (ASCII_Unicode_CPC.pdf, version 2.2 and higher) is adjusted to the SWPM and new zip files are attached to add the In-place functionality to the 70SWPM/SWPM installer (InplaceCPC70x.zip/InplaceCPC7XX.zip). The old SAPinst/TMKSVR procedure is obsolete now and will not be supported any longer.
Especially SAP products with a large database as for example the SAP ERP 6.0 EHP7 can benefit by a significant performance improvement when using the In-place CPC while converting a Latin-1 code page database to Unicode.
Hello Mr Buescher,
do you have any information about the additional size the database has after the conversion?
Kind regards
Rüdiger Höckel
apetito AG
Dear Mr. Höckel,
different to other databases on IBM DB2 for i the in-place conversion keeps the original db schema. Only the content of a few tables is converted. (That's the trick.) ASCII and Unicode tables have already the same size and for the codepage 1100 they have even the same content. The tables which have to be converted like clustered and pooled tables will not change their size that much. Sometimes they even become smaller because a better compression algorithm is used now.
For that the database size should not change much.
Kind regards, Ralf Büscher
Hello Mr Buescher,
Thanks for this excellent post . Currently we are doing CUCC ( NUN ECC5 to UN ECC6 EHP7 )in IBM i series . We like to test this approach . Our DB size is 7.2 there are multiple transparent (GLPCA)and cluster table(RFBLG) which are more that 500 GB of size . SO we like to use table splittig feature as well.
However we have some doubts
1. As I understand in place CPC convert some of the transparent table and cluster table .How will the table split feature treat this scenario during table splitting. If the transparent table are splitted will they also be exported bu the in place CPC.
2. As per the guide it is mentioned we only need to extract the new UC kernel manually before starting In-place CPC import . Will The SWPM not be able to extract UC kernel in installation process automatically.
Regards,
Ibrahim
Dear Mr. Mondal, To question 1.: Transparent tables will not be exported using the In-place CPC. The R3Load running within the export is the central tool to split, to extract and to convert the data. On IBM i the R3Load has an additional feature to identify clustered and pooled tables. By default only clustered and pooled tables are exported within an In-place CPC. As transparent tables are not clustered or pooled anymore their content is Latin-1 which not has to be converted anymore! To question 2.: Currently the In-place CPC is not be able to switch the Non-Unicode kernel to the Unicode kernel automatically. The switch has to be done manually as described in the documentation. The background is: Experienced consultants want have full control of the kernel switch by using their own already tested and patched Unicode kernel. Especially after the switch these consultants want to check the logs of the APYSIDKRN to check if there are additional information. Kind regards, Luis Gonzalez