Overview of Unicode
Fundamentally, computers deal with just numbers. Characters are converted to predetermined numbers in order to be stored in the system. For example in the ASCII encoding “A” is stored as 65 (Dec) and “a” as 97 (Dec). As the need to store characters from different languages arose, different forums were formed to create different code pages that would suit their requirement. However, there was no order maintained to ensure that the numbers consumed by characters in other code pages are not reused. Soon there was a mess with different characters being represented by the same number in different code pages and also because of the repetition of some of these characters.
To alleviate the problems associated with data transfer between different encodings or platforms, the Unicode Consortium was formed in 1991 in California, USA. The Unicode Consortium is a non-profit based organization founded to develop, extend and promote use of the Unicode Standard, which specifies the representation of text in modern software products and standards.
Unicode is now an internationally accepted standard that assigns characters from virtually every language and scripts a unique Unicode Scalar Value, which is a number written in hexadecimal notation. Unicode currently defines over 98,000 characters, with room for over 1 million characters. Unicode defines each character only once. Unicode can be used for the system code page, front end and printing.
Unicode Conversion in SAP –
To conduct business in multiple languages in SAP, it was required to deploy the appropriate code page (on versions 4.6c and below). The table TCPDB contains the number of code pages deployed. Each code page can support one or more language. Systems having multiple code pages deployed are referred to as MDMP (Multi Display Multi Programming) systems. In SAP R/3 4.7 SAP introduced the Unicode concept. However SAP continued to support the MDMP installations too. In June 2006 SAP released ERP 6.0 and with this version stopped supporting MDMP altogether, which means that Unicode conversion for such implementations has become mandatory. Single code page systems can continue to operate in ERP 6.0 in a non Unicode environment.
Approaches for Unicode Conversion:
§ Combined Upgrade and Unicode Conversion (CUUC)
§ Twin Upgrade and Unicode Conversion (TUUC)
General Restrictions on conversion to Unicode –
1. You cannot install a Unicode system with a non-Unicode system in one database (MCOD).
DB2-z/OS: Read SAP Note 1068215 for information about MCOD with Unicode and non-Unicode systems on DB2-z/OS.
2. SAP Systems which deploy one or more EBCDIC code pages (= code pages with SAP internal numbers < 1000) cannot be converted to Unicode:
a. Run transaction SE11 and check if database table TCPDB contains entries < 1000.
b. If yes, the system must be converted to ASCII first.
3. SAP Unicode systems are not released for Informix.
4. Conversion from Unicode to non-Unicode is not possible.
5. Note the restrictions for Unicode Solution Manager monitoring non-Unicode systems with MaxDB database (SAP Note 924650).
Range of additional Resource Consumption
UTF- 8: +10%
Add. Storage Req’s
DB2 (Universal Database for Unix / NT)
DB2 for AS/400
DB2 for z/OS
Customers with Asian system code pages (Japanese, Korean, Simplified Chinese, and Traditional Chinese) that have been using the user definable areas are advised to read SAP Note 726954 to check the mapping of the user defined characters to Unicode.
To convert a non-Unicode system to Unicode, all character data in the non-Unicode database must be converted to Unicode. The default conversion method is to export the entire database using SAPinst, create a new Unicode database (system copy), and then import the database using SAPinst again. The actual data conversion to Unicode is done during the export. More information about system copy optimization is available at www.service.sap.com/systemcopy -> optimization.
When planning a Unicode conversion a rough estimation of the expected downtime can be done by using a calculation formula attached to SAP Note 857081. The downside to this calculation is that SAP states that the actual downtime might range from -50% to +100% of what has been arrived at by using this formula. This SAP Note also provides an overview of different system copy optimization tools and methods.