Unicode Conversion Preparation

This Presentation is MDMP / Ambiguous Blended Code

page specific

Created By : Sumit Kothiyal Role : Basis

Consultant

1
 Conversion Preparation

This chapter explains the steps involved in the pre-

conversion preparation of the MDMP / Unambiguous
blended code page SAP Systems.
1. ABAP Preparation System: Web AS 6.20 non-
Unicode.
2. Unicode enabled ABAP and C/C++ programs.

2
 Upgrade Path to the Unicode ( R/3
Enterprise)

Concept: Before the database conversion to the

Unicode is executed all the text data must be assigned
the correct code page

3
 Concept Contd:

Single Code Page Systems and Unambiguous Blended

Code page systems are easy to get converted into
Unicode.

MDMP and Ambiguous Blended Code Page systems

conversion is complex in nature.

4
 Why MDMP/Ambiguous Conversion is
complex?

Look at the content of the MDMP System as shown in

the below diagram:

5
Content of the Unicode system is as shown below in
comparison to the above diagram:

6
 Concept: Conversion Preparation

Code page assignment in MDMP/Ambiguous Blended

Code Page Systems is complex because all the rows of
the tables in the Database must be assigned a Code
Page.

Solution of the above problem:

A). Use existing language keys
B). System Vocabulary = Word – Language assignment
( Word= contains characters outside common
character set )

7
 SPUMG : Conversion Preparation

Unicode Conversion: The transaction used for the

conversion information which will be used during the
export/import of the Database in the actual Unicode
conversion to keep the data consistent.

8
 SPUMG Contd.

This is actually a tool for the database analysis for

collecting words without language or code page
information. SPUMG creates control information which
is later used for the conversion as explained earlier.
SPUMG consists of the several Scan levels:
•Consistency checks
•Tables without language information ( Table 1)
•Tables with Ambiguous language information
•Tables with language information.
•Reprocess.
•INDX Table Analysis.
•INDX Table repair.

9
SPUMG: Language Lists

10
SPUMG Settings: Maintain the SPUMG settings and
then initialize the worklist for the Consistency checks

11
Consistency Checks:
•Classifies tables into tables with/without language
filed information ( Table category 1 and 2 ).
•Checks table consistency ( existence, access)
•Writes control information to SPUMG control tables
( Table category, Language Field)

12
Tables without Language Information: This scan adds
words to the system Vocabulary and all the all the
tables without language ( Table category 2 )
information are scanned.

13
Tables with Ambiguous Language Information: All the
tables with language information ( Table Category 1 )
are scanned. Words with an ambiguous language are
added to the System Vocabulary.
Only active if ambiguous language list has been
maintained.

14
 System Vocabulary

System vocabulary must be maintained before the

database is exported.
You can do the following:
•Insert the language keys automatically on scan level
tables with language information.
•Create the Vocabulary hints to assign the language
based on the other table fields.
•Manually assign the language to word in the system
Vocabulary.
•Reuse the existing language code page assignments
imported from the other systems or delivered by the
SAP (sapnotes 756534 and 756535 )

15
Tables with Language Information: All tables with the
language information are scanned ( Table category 1 ).
This scan assign the language to the words in the
System Vocabulary based on the values of the other
tables in the database.
Only problem could be Vocabulary Collisions.

16
Reprocess: This scan simulates the R3load behavior. It
checks if the code page information in the System
Vocabulary is sufficient for the conversion. If not, this
scan creates a repair Log for the table. ( Row identifier
+ Language assignment )

17
Reprocess Repair Log : It contains table name, key
values, reason why no code page could be assigned.
Users can assign a language to each entry here. This
information is used in the Unicode system to repair
wrongly converted data.
INDX-type Tables: Special Treatment

Why must these tables be scanned separately ?

The answer is these tables consists of :

1. A transparent part which is treated like the other
transparent tables in the database during the conversion
preparation.

2. A binary part which contains the code page information

used during the Export to database/Import to database
statement.

Note :In MDMP systems the previous handling of the INDX-type

tables was improper in a way that a wrong code page might be
stored in the binary part of the table.

18
Structure of the INDX-type tables as shown in the
below diagram:

19
INDX-type table repair/analysis : These two scans treat
the binary part of INDX-type tables:
1. All INDX-type tables without language information
are scanned and all the text hidden in the INDX-cluster
part is analyzed. Words are added to the system
Vocabulary.
2. System Vocabulary is used for assigning correct
code pages before the database export.

20
Final steps in the non-Unicode systems

Newly created tables can be added to SPUMG by

updating the Worklist. You can display the new tables
in the update log.

21
 Database Export, Conversion and
Import
The system setup tool SAPinst is used for the entire system
copy – internally SAPinst uses the program R3load.R3load
performs the database export with the conversion to Unicode
using the control table and System Vocabulary, writes an
R3load Repair log in case the code information is not
available, and performs the database import. As a system
copy to Unicode, database conversion and system shutdown /
Unicode system start will be completely automated.

22
R3load – Export :
SAPinst uses a program R3load as a Frontend tool for
the database export.
Logs are written to the SAPinst Directory
Export files are written to the Export Directory

R3load – Import :
SAPinst uses a program R3load as a Frontend tool for
the database import.
Non-UC DB can be deleted ( not recommended) or UC
DB can be installed on the new / different server.
Import method is same as new installation.

23
 R3load – Export

Export phase as Shown in the diagram below:

24
 R3load -- Import

Import phase as Shown in the diagram below:

25
 Unicode System: Initial Steps
1. Update the kernal and other executables
2. Start the Server.
3. Logon to the Unicode System and run SICK.
See the diagram below for the overview:

26
 SUMG: On the UC System

SUMG: Post- conversion repair in the Unicode

converted system

27
SUMG: After the database import there might be some
data in the Unicode system which need to be
“repaired”. In this case the data can be converted
again, using the correct language information (code
page).
SUMG has several repair methods:
1. Repair Jobs, using the R3load Repair Log and the
language information of the SPUMG reprocess Log.
2. Repair Hints.
3. Manual Repair.

28