Reg:Unicode checking

Former Member · ‎08-02-2007

Please tell me wht are the diffarent tools those we use for unicode checking

Thanks,

Srik

Former Member · ‎08-02-2007

Check <b>UCCHECK</b> TCode

Also refer these related threads

Message was edited by:

Santosh Kumar Patha

seshatalpasai_madala · ‎08-02-2007

Hi,

You need to use the transaction UCCHECK.

The report documentation is here

ABAP Unicode Scan Tool UCCHECK

You can use transaction UCCHECK to examine a Unicode program set for syntax errors without having to set the program attribute "Unicode checks active" for every individual program. From the list of Unicode syntax errors, you can go directly to the affected programs and remove the errors. It is also possible to automatically create transport requests and set the Unicode program attribute for a program set.

Some application-specific checks, which draw your attention to program points that are not Unicode-compatible, are also integrated.

Selection of Objects:

The program objects can be selected according to object name, object type, author (TADIR), package, and original system. For the Unicode syntax check, only object types for which an independent syntax check can be carried out are appropriate. The following object types are possibilities:

PROG Report

CLAS Class

FUGR Function groups

FUGX Function group (with customer include, customer area)

FUGS Function group (with customer include, SAP area)

LDBA Logical Database

CNTX Context

TYPE Type pool

INTF Interface

Only Examine Programs with Non-Activated Unicode Flag

By default, the system only displays program objects that have not yet set the Unicode attribute. If you want to use UCCHECK to process program objects that have already set the attribute, you can deactivate this option.

Only Objects with TADIR Entry

By default, the system only displays program objects with a TADIR entry. If you want to examine programs that don't have a TADIR entry, for example locally generated programs without a package, you can deactivate this option.

Exclude Packages $*

By default, the system does not display program objects that are in a local, non-transportable package. If you want to examine programs that are in such a package, you can deactivate this option.

Display Modified SAP Programs Also

By default, SAP programs are not checked in customer systems. If you also want to check SAP programs that were modified in a customer system (see transaction SE95), you can activate this option.

Maximum Number of Programs:

To avoid timeouts or unexpectedly long waiting times, the maximum number of program objects is preset to 50. If you want to examine more objects, you must increase the maximum number or run a SAMT scan (general program set processing). The latter also has the advantage that the data is stored persistently. Proceed as follows:

- Call transaction SAMT

- Create task with program RSUNISCAN_FINAL, subroutine SAMT_SEARCH

For further information refer to documentation for transaction SAMT.

Displaying Points that Cannot Be Analyzed Statically

If you choose this option, you get an overview of the program points, where a static check for Unicode syntax errors is not possible. This can be the case if, for example, parameters or field symbols are not typed or you are accessing a field or structure with variable length/offset. At these points the system only tests at runtime whether the code is sufficient for the stricter Unicode tests. If possible, you should assign types to the variables used, otherwise you must check runtime behavior after the Unicode attribute has been set.

To be able to differentiate between your own and foreign code (for example when using standard includes or generated includes), there is a selection option for the includes to be displayed. By default, the system excludes the standard includes of the view maintenance LSVIM* from the display, because they cause a large number of messages that are not relevant for the Unicode conversion. It is recommended that you also exclude the generated function group-specific includes of the view maintenance (usually L<function group name>F00 and L<function group name>I00) from the display.

Similarly to the process in the extended syntax check, you can hide the warning using the pseudo comment ("#EC *).

Applikation-Specific Checks

These checks indicate program points that represent a public interface but are not Unicode-compatible. Under Unicode, the corresponding interfaces change according to the referenced documentation and must be adapted appropriately.

View Maintenance

Parts of the view maintenance generated in older releases are not Unicode-compatible. The relevant parts can be regenerated with a service report.

UPLOAD/DOWNLOAD

The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.

Regards,

Sesh

Former Member · ‎08-02-2007

Hi,

About brief idea about unicode

In the past, SAP developers used various codes to encode characters of different alphabets, for example, ASCII, EBCDI, or double-byte code pages.

ASCII (American Standard Code for Information Interchange) encodes each character using 1 byte = 8 bit. This makes it possible to represent a maximum of 28 = 256 characters to which the combinations [00000000, 11111111] are assigned. Common code pages are, for example, ISO88591 for West European or ISO88595 for Cyrillic fonts.

EBCDI (Extended Binary Coded Decimal Interchange) also uses 1 byte to encode each character, which again makes it possible to represent 256 characters. EBCDIC 0697/0500 is an old IBM format that is used on AS/400 machines for West European fonts, for example.

Double-byte code pages require 1 or 2 bytes for each character. This allows you to form 216 = 65536 combinations where usually only 10,000 - 15,000 characters are used. Double-byte code pages are, for example, SJIS for Japanese and BIG5 for traditional Chinese.

Using these character sets, you can account for each language relevant to the SAP System. However, problems occur if you want to merge texts from different incompatible character sets in a central system. Equally, exchanging data between systems with incompatible character sets can result in unprecedented situations.

One solution to this problem is to use a code comprising all characters used on earth. This code is called Unicode (ISO/IEC 10646) and consists of at least 16 bit = 2 bytes, alternatively of 32 bit = 4 bytes per character. Although the conversion effort for the R/3 kernel and applications is considerable, the migration to Unicode provides great benefits in the long run:

The Internet and consequently also mySAP.com are entirely based on Unicode, which thus is a basic requirement for international competitiveness.

Unicode allows all R/3 users to install a central R/3 System that covers all business processes worldwide.

Companies using different distributed systems frequently want to aggregate their worldwide corporate data. Without Unicode, they would be able to do this only to a limited degree.

With Unicode, you can use multiple languages simultaneously at a single frontend computer.

Unicode is required for cross-application data exchange without loss of data due to incompatible character sets. One way to present documents in the World Wide Web (www) is XML, for example.

ABAP programs must be modified wherever an explicit or implicit assumption is made with regard to the internal length of a character. As a result, a new level of abstraction is reached which makes it possible to run one and the same program both in conventional and in Unicode systems. In addition, if new characters are added to the Unicode character set, SAP can decide whether to represent these characters internally using 2 or 4 bytes.

A Unicode-enabled ABAP program (UP) is a program in which all Unicode checks are effective. Such a program returns the same results in a non-Unicode system (NUS) as in a Unicode system (US). In order to perform the relevant syntax checks, you must activate the Unicode flag in the screens of the program and class attributes.

In a US, you can only execute programs for which the Unicode flag is set. In future, the Unicode flag must be set for all SAP programs to enable them to run on a US. If the Unicode flag is set for a program, the syntax is checked and the program executed according to the rules described in this document, regardless of whether the system is a US or an NUS. From now on, the Unicode flag must be set for all new programs and classes that are created.

If the Unicode flag is not set, a program can only be executed in an NUS. The syntactical and semantic changes described below do not apply to such programs. However, you can use all language extensions that have been introduced in the process of the conversion to Unicode.

As a result of the modifications and restrictions associated with the Unicode flag, programs are executed in both Unicode and non-Unicode systems with the same semantics to a large degree. In rare cases, however, differences may occur. Programs that are designed to run on both systems therefore need to be tested on both platforms.

You can also check out these official SAP locations on the SAP Service Marketplace:

http://service.sap.com/unicode

http://service.sap.com/unicode@SAP

http://service.sap.com/i18n

Regards