sapnote_0000932779

21.08.2011 of 8

SAP Note 932779 - Unicode conversion - analysis ofnametab problems

Note Language: English Version: 16 Validity: Valid Since 09.07.2010

Summary

SymptomR3load errors during Unicode conversion or Runtime error in newly convertedUnicode system. Inconsistent Unicode nametab is assumed to be the cause ofthe problem.

Other termsRADCUCNT, Unicode conversion, DDNTT, DDNTF, DDXTT, DDXTF, Unicode nametab,DDNTT_CONV_UC, DDNTF_CONV_UC, DDXTT_CONV_UC, DDXTF_CONV_UC

Reason and PrerequisitesThis document describes some facts about nametabs and problems which mightoccur during the Unicode conversion of a system. The document is notthought as reference information for nametabs. It might help to understandthe nametab handling in the Unicode conversion procedure and might helpwhen analyzing problems.

SolutionContents

1. Basics1.1 What are the nametabs ?1.2 Where can I find the nametabs ?1.3 How can I look in the nametabs ?

2. Nametabs and Unicode conversion2.1 The nametab switch during conversion2.2 Known problems2.3 Analyzing problems

3. Nametabs and CU&UC3.1 The nametab handling during CU&UC3.2 Analyzing problems

1. Basics*********

1.1 What are the nametabs ?===========================

The nametabs are database tables which contain the basic technicaldefinitions of a dictionary object (domain, data element, table, structure,...). The ABAP interpreter needs the nametabs to execute an ABAP program.Each time a dictionary object is created or modified, the correspondingnametabs are updated.

Without a nametab, a system cannot run !

1.2 Where can I find the nametabs=================================

There are several different nametabs. Here is a list of (all ?) nametabs:

21.08.2011 of 8


DDNTT : Active nametab containing all dictionary objects.DDNTF : Active nametab containing field information for tables/structure

DDXTT : Corresponding inactive nametab to DDNTTDDXTF : Corresponding inactive nametab to DDNTF

DDNTT_CONV_UC : Alternative nametab, corresponding to DDNTTDDNTF_CONV_UC : Alternative nametab, corresponding to DDNTFDDXTT_CONV_UC : Alternative nametab corresponding to DDXTTDDXTF_CONV_UC : Alternative nametab corresponding to DDXTF

In a running system, only the nametab tables DDNTT and DDNTF are used. Theactive nametabs must be completely and correctly filled at system startup.If objects are modified, the nametab tables DDXTT and DDXTF are used tostore changes temporarily. If an object is activated the correspondingentry is deleted in the DDXTT and DDXTF tables and updated in the DDNTT andDDNTF tables.

The tables DD*_CONV_UC are not used at all ! They are used only during theexport/import procedure of a database with SAPinst and R3load; the standardUnicode conversion of a system fills these tables before the export withUnicode specific (eg: length) information, and exchanges active andalternative nametabs during import.

1.3 How can I look into the nametabs ?====================================

DDNTT / DDNTF tables

The tables DDNTT/F exist on database level only. They are not defined inthe SAP dictionary. Contents can be displayed with the function module'DD_SHOW_NAMETAB'. Use the "Status" parameter to look in the active (Status= A) or inactive (Status = I) nametabs.

A corresponding function modules exists for the alternative nametab tablesDDNT*_CONV_UC tables. It is called 'DD_SHOW_UC_NAMETAB'.

Among other information, you can see 3 different timestamps in the outputof the function modules:

CRSTAMP: This timestamp is set whenever the object is activated.

ABSTAMP: This timestamp is set if an ABAP relevant change was done to thetable. If an ABAP program needs to be executed, the ABAP looks if theprogram needs to be generated first. It checks all timestamps of dependenttables and compares them to the timestamp of the program. If any timestampof a table is newer than the last generation of the program, then theprogram is generated.

DYSTAMP: This timestamp is set if a dynpro relevant change was done for theobject. If a dynpro screen needs to be executed, the DYNP looks if thescreen needs to be generated first. It checks all timestamps of dependenttables and compares them to the timestamp of the screen. If any timestampof a table is newer than the last generation of the screen, then the screenis generated.

The CRSTAMP and ABSTAMP timestamps are very important for the Unicode

21.08.2011 of 8


conversion. Other important fields are the DDLn parameter or the Offsparameter which specifies the field length and offsets to be used instructures. The contents for the latter parameter differ in a non Unicodeand Unicode system.

DDXTT / DDXTF tables

The DDXTT and DDXTF tables exist in the SAP dictionary also. Therefore theycan be accessed easily via transaction SE16.

2. Nametabs and Unicode conversion**********************************

You might wonder why we need two sets of nametabs (DDNT* and DDNT*CONV_UC)because only the active nametabs DDNTT and DDNTF are used in a system. Butas we have learned above, a system cannot live without complete activenametabs AND a Unicode system cannot run with the active nametabs createdfrom a non Unicode system.

Therefore we do the following:

1. Create the active nametabs which can be used in the Unicode systembefore the Unicode conversion.

The nametab tables used in a Unicode system are generated with reportRADCUCNT. Such a generation takes several hours. After the generation,dictionary objects must not be changed anymore, because the previouslycreated Unicode nametabs would be out of date then.

2. Store the nametabs in other tables.

The Unicode nametabs are stored in the alternative nametab tablesDDNTT_CONV_UC and DDNTF_CONV_UC (the pattern *_CONV_UC might bemisleading because the tables DD*_CONV_UC tables might contain alsothe non Unicode version of the active nametabs).

3. Exchange the nametabs during the Unicode conversion, i.e. during theimport of the database.

The exchange of the nametabs is done during the import of the Unicodedatabase. This is discussed in detail in the next section.

2.1 The nametab switch======================

The following steps describes in detail how the nametabs are exchanged:

1. You are in a Non Unicode System. All Unicode preparation steps have beenaccomplished. So you have the nametab tables:

DDNTT: Active nametabDDNTF: Active nametab

DDNTT_CONV_UC: Nametabs filled by RADCUCNT, based on the information ofDDNTT and the dictionary sources

21.08.2011 of 8


DDNTF_CONV_UC: Nametab filled by RADCUCNT, based on the information ofDDNTF and the dictionary sources

DDX* tables must be empty !

2. Now you do the Unicode export of the database with R3load. The nametabsare exported with the package SAPSDIC or SAPNTAB depending on basisrelease. During the export, several files are created by R3load whichcontain meta information about package contents. Let's have a closer lookat the files with the extension .TOC (table of contents):

For each table you will find an entry like------------------tab: DF35Sfil: SAPSDIC.001 1024128840 128921eot: #7146 rows 20050630211953------------------"tab:" specifies the table name"fil:" specifies the data file which contain the table contents"128840 128921": the two numbers specify the position of the data in file"fil:""eot:" shows the number of rows which have been exported and a timestamp

For the entries above you know that 7146 rows of table DF35S have beenexported to file SAPSDIC.001 on 30th June 2005.

In the SAPSDIC.TOC or SAPNTAB.TOC file, you can see also the handling ofthe nametab tables. For the nametab tables special table names are used:DDNTT is exported as table DDNTT_1B, table DDNTT_CONV_UC is exported astable DDNTT_2B. (1B = 1 Byte, 2B = 2 Byte):------------------tab: DDNTT_1Bfil: SAPSDIC.001 1024109947 120222eot: #402222 rows 20050630211910tab: DDNTT_2Bfil: SAPSDIC.001 1024120223 131746eot: #402187 rows 20050630211934------------------402222 rows of table DDNTT have been exported to file SAPSDIC.001 on 30thJune 2005 and 402187 rows of table DDNTT_CONV_UC have been exported to fileSAPSDIC.001 on 30th June 2005.

You will find similar entries for the inactive nametab tables DDX* inpackage SAPSSEXC (file SAPSSEXC.TOC). But as mentioned above, the inactivenametabs must empty. Otherwise you might have a lot of problems whenstarting your Unicode system (see Unicode Conversion Guide for details).

3. The nametab switch is finally done during the import of data into theUnicode database. In the Unicode database, R3load creates the tables DDNTTand DDNTT_CONV_UC and now the contents of DDNTT_1B is imported into tableDDNTT_CONV_UC and the file contents of DDNTT_2B is imported into tableDDNTT, i.e. the table contents of DDNTT and DDNTT_CONV_UC are exchanged.

Summary

21.08.2011 of 8


The contents of the active nametabs DDNTT and DDNTF are exchanged duringthe Unicode export and import of a database by the contents of thealternative nametab table DDNTT_CONV_UC and DDNTF_CONV_UC. The activenametabs are DDNTT and DDNTF in the non Unicode system and the Unicodesystem.

Non Unicode Unicode Export Files Import UnicodeSystemSystem Export

+---------------+ +---------------++---------------+| DDNTT | ---------> | DDNTT_1B | --+ +----> |DDNTT |+---------------+ +---------------+ \ /+---------------++---------------+ +---------------+ \ /+---------------+| DDNTF | ---------> | DDNTF_1B | --+ \ / +----> |DDNTF |+---------------+ +---------------+ \ \ / /+---------------+ | \ X / | Generated by \/ \/ | report RADCUCNT /\ /\ V / X \+---------------+ +---------------+ / / \ \+---------------+| DDNTT_CONV_UC | ---------> | DDNTT_2B | --+ / \ +----> |DDNTT_CONV_UC |+---------------+ +---------------+ / \+---------------++---------------+ +---------------+ / \+---------------+| DDNTF_CONV_UC | ---------> | DDNTF_2B | --+ +----> |DDNTF_CONV_UC |+---------------+ +---------------++---------------+

In the Unicode system, the nametab tables DD*CONV_UC are not neededanymore. The same picture can be drawn for the DDX* tables.

2.3 Analyzing problems======================

From the discussions above you see that is it crucial that the alternativenametabs DDNTT/F_CONV_UC are created correctly by RADCUCNT and that theactive nametabs are not changed anymore after the alternative nametabs havebeen generated. The active nametabs are changed each time you modify adictionary object, e.g. by importing a transport request, applying asupport package or just by modifying it manually. Most often this resultsin short dumps or syntax errors in the Unicode system or more tragicallythe system even does not start after import.

21.08.2011 of 8


If you think that something is wrong with the nametabs you should check thecontents of the nametab tables.

o Find out in which package the nametab tables have been exported(most often SAPSDIC or SAPNTAB).

o Look for the DDNTT_1B and DDNTT_2B entries in the corresponding.TOC file created during export. The number of rows exported forDDNTT_1B and DDNTT_2B must be (almost) the same !

Example: If you find

------------------

tab: DDNTT_1B

fil: SAPSDIC.001 1024

109947 120222

eot: #402222 rows 20040217112728

tab: DDNTT_2B

fil: SAPSDIC.001 1024

120223 135746

eot: #122187 rows 20040217113208

------------------

in SAPSDIC.TOC, you know that the alternative nametabs were notcreated correctly because only 122187 rows have been exported fortable DDNTT_2B whereas the active nametab of the non Unicode systemcontained 402222 rows. In such a case, the Unicode system will notstartup after import. The alternative nametabs have to be generated inthe non Unicode system and the export of the corresponding SAPSDICpackage has to be done once more.

Please note: we observed that even when the nametabs have beengenerated correctly, there is always a small mismatch between theDDNTT_1B and DDNTT_2B tables. But the difference of the number of rowsshould not be greater than about 25-50 entries.

o Another common problem is that the Unicode nametabs are out ofdate. It means that the active nametabs have been modified afterthe generation of the alternative nametabs.

How to check this ?

Get access to the non Unicode database for the tables DDNTT andDDNTT_CONV_UC. Compare the field ABSTAMP for DDNTT and DDNTT_CONV_UC.If you find a timestamp in DDNTT which is younger than thecorresponding timestamp in DDNTT_CONV_UC, the alternative nametab isout of date (at least for this record). You can do this check also in

21.08.2011 of 8


the Unicode database, but rememeber the nametab switch !

o If nametab entries in the Unicode system are inconsistent and thereason is not clear. Check timestamp of the nametab entry and lookin log files, what happened at this timepoint. Candidates forrelevant log files are:

RADCUCNT log

SAPINST log

Upgrade log

Transport log

o Sometimes only a few runtime objects are out of date. If theUnicode system is running, you can use transaction SE11 to activatethe objects in question. During activation, the runtime object,i.e. the nametab entry is generated from the dictionary sources.

o If you have access to the database(s) you can read out the contentsof tables DDNTT and DDNTT_CONV_UC directly. Please remember thenametabs switch when comparing the table contents between nonUnicode and Unicode database !!

3. Nametabs and CU&UC**********************

During CU&UC (Combined Upgrade and Unicode Conversion) the nametab istouched twice. Once for upgrade and once for Unicode Conversion.The upgrade starts working on a shadow system. The table names in theshadow system are derived form the original table names by adding a '~'ShadowTableName = OriginalTableName~

3.1 The nametab handling during CU&UC=====================================

Phase RADCUCNT_ALLDDXTT~ contains non-Unicode nametab of the target release which isdelivered by SAP.RADCUCNT is run to create Unicode nametab from DDXTT~ into DDNTT_CONV_UC~

Creation of non-Unicode nametab of target releaseDDNTT~ contains customer nametab from start release (including customerextensions)From the difference between DDXTT~ and DDNTT~ the necessary DB adaptionsaredetermined and executed. AfterwardsDDNTT~ = non-Unicode nametab of target releaseDDXTT~ = emptyDuring the offline phase of the upgrade DDNTT~ becomes the active nametab

Phase RADCUCNT_NEWRADCUCNT runs to update Unicode nametab from DDNTT~ into DDNTT_CONV_UC~ forall objects that have been touched during upgrade

During Unicode conversion preparation (SPUM4/SPUMG) RADCUCNT runs againtwice, once for all objects that came new in the meantime (e.g. from

21.08.2011 of 8


support packages) and once for all objects that have been touched in themeantime.

3.2 Analyzing problems======================

RADCUCNT logs for runs during upgrade are written to<DIR_PUT>/log/Radcucnt*.RADCUCNT logs for runs during SPUM4/SPUMG are written to SPUM4/SPUMGtables.For manual calls to RADCUCNT (should be avoided) the logfile is specifiedby the caller.

Note: The size of data elements in Unicode nametab is calculated from thenon-Unicode nametab specified as source nametab to RADCUCNT. The size ofall other nametab objects is calculated from the sources. So wrong sizes ofdata elements in Unicode nametab is probably caused by problems withRADCUCNT.

Header Data

Release Status: Released for CustomerReleased on: 09.07.2010 11:24:54Master Language: EnglishPriority: Recommendations/additional infoCategory: Help for error analysisPrimary Component: BC-I18-UNI I18N Unicode

Valid Releases

Software Component Release FromRelease

ToRelease

andSubsequent

SAP_BASIS 60 610 640

SAP_BASIS 70 700 700

SAP_BASIS 71 710 710 X

Related Notes

Number Short Text

1428028 Unicode Conversion: check nametabs report UMG_CHECK_NAMETABS

1426513 Unicode Conversion: check nametab tables

1319517 Unicode Collection Note

837173 RADCUCNT in Unicode Conversion: Collective Note

614550 Troubleshooting BC-I18

548016 Conversion to Unicode

sapnote_0000932779

Documents