Unicode Programs

[Former Member]

Hi all,

How to restrict the unicode programms

Thanks.

[Former Member]

Hi Mathitha,

I am not sure if i can get you...but if you are referring to enable Unicode check then there is checkbox in program attribute "Unicode Checks Active".. You can tick this checkbox to make your program Unicode enabled.

Regards,

Mohaiyuddin

[Former Member]

The Link will be helpful to you.

Very good document:

http://www.doag.org/pub/docs/sig/sap/2004-03/Buhlinger_Maxi_Version.pdf

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d37d1ad9-0b01-0010-ed9f-bc322231...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/589d18d9-0b01-0010-ac8a-8a228520...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f8e316d9-0b01-0010-8e95-829a58c1...

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.

Reward points if useful

[Former Member]

Hi Mahitha,

The adjustments you have to make and the restrictions that apply in the Unicode context have been limited to the essentials on the ABAP development side to keep the conversion effort for ABAP users to a minimum. In some cases, however, this has led to the emergence of more complex rules, for example, with regard to assignments and comparisons between incompatible structures.

ABAP Development under Unicode

Prior to Unicode the length of a character was exactly one byte, allowing implicit typecasts or memory-layout oriented programming. With Unicode this situation has changed: One character is no longer one byte, so that additional specifications have to be added to define the unit of measure for implicit or explicit references to (the length of) characters.

Character-like data in ABAP are always represented with the UTF-16 - standard (also used in Java or other development tools like Microsoft's Visual Basic); but this format is not related to the encoding of the underlying database.

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 a 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.

Other Changes

Bit Statements

Adding Field Sequences

Loops with VARY and VARYING

Creating Subroutines

Saving Programs

Assigning Types for GET/SET PARAMETER

Unreachable Statements

Function Modules with Incorrect Parameter Names

1. Bit StatementsPreviously, the system checked for the bit statements SET BIT i OF f [TO g] and GET BIT i OF f [INTO g]whether the field f is character-type; X fields, X strings, and flat structures are usually regarded as character-type. For Unicode programs this is no longer useful, because the types X and XSTRING no longer count as character-type and the bit by bit access to character-type fields or structures is no longer platform-independent. Therefore, with these operations in Unicode programs, the field f must be type X or XSTRING.For the bit mask operations f O x, f Z x, and f M x you could previously use all number-type and hence all character-type types for the left operand f. In Unicode programs, the f operand must now be type X or XSTRING.

2. Adding Field SequencesWhen adding field sequences, restrictions apply to the following statements in Unicode:ADD n1 THEN n2 UNTIL nz [ ACCORDING TO sel ] GIVING m ...ADD n1 THEN n2 UNTIL nz TO m [ RANGE str ].

The operands n1, n2, and nz must be type-compatible with one another.

The distance between nz and n1 must be an integral multiple of the distance between n2 and n1.

A syntax or runtime error occurs if the fields n1, n2, and nz are not in a structure. This structure must be recognizable statically or its valid area must be marked explicitly using the RANGE addition.

At runtime, the system ensures that the RANGE area is not left.

ADD n1 FROM i1 GIVING m [ RANGE str ].

Field n1 must be within the structure. The structure must be explicitly defined using the RANGE addition if it is not recognizable statically.

For this variant, the system also checks at runtime whether n1 and the addressed values are within the structure.

3. LoopsLoops with the VARY or VARYING addition are also problematic in Unicode, since a type-a access to memory contents cannot be ensured and memory can be overwritten inadvertently. DO ... VARYING f FROM f1 NEXT f2.For this statement, the fields f, f1, and f2 must be type-compatible with each other. To prevent memory contents being overwritten, a RANGE for valid accesses is introduced implicitly or explicitly for the following statements:DO ... TIMES VARYING f FROM f1 NEXT f2 [ RANGE f3 ].WHILE ... VARY f FROM f1 NEXT f2 [ RANGE f3 ].A syntax or runtime error is caused if f1 or f2 are not included in f3. If the RANGE addition is missing, it is defined implicitly from FROM f1 NEXT f2 as follows:

If both f1 and f2 are statically recognizable components of the same structure, the valid RANGE area is defined from the smallest structure that comprises f1 and f2.

A syntax error is triggered if it is recognizable statically that f1 and f2 are not part of the same structure.

A valid area must be defined explicitly using the RANGE addition if the connection between f1 and f2 is not recognizable statically.

If you specify a deep structure as the RANGE addition, the system checks for every loop pass that there are no field references, object references, tables, or strings in the area read.

4. Creating SubroutinesWhen automatically generating subroutines using the statement GENERATE SUBROUTINE POOL itab NAME name, the generated program inherits the content of the Unicode flag of the generating program.

5. Saving ProgramsWhen automatically generating programs using the statement INSERT REPORT prog FROM itab, default values are set for the TRDIR entry as before. Amongst other things, this statement has the new addition UNICODE ENABLING uc, with which the Unicode flag of the inserted report receives the value of uc. If this addition is missing, the following applies:

A Unicode program creates a Unicode program.

A non-Unicode program in turn creates a non-Unicode program.

A non-Unicode program becomes a Unicode program if it is overwritten by a Unicode program.

A Unicode program remains a Unicode program if it is overwritten by a non-Unicode program.

6. Assigning Types for GET/SET PARAMETERFor the statements GET PARAMETER ID pid FIELD f and GET PARAMETER ID pid FIELD f, f must be character-type. You can use the EXPORT and IMPORT statements for storing non-character-type fields and structures.

7. Unreachable StatementsIn Unicode programs, unreachable statements cause a syntax error. In non-Unicode programs, there was previously only a syntax warning.

8. Function Modules with Incorrect Parameter NamesIn Unicode programs, calling a function module, whose parameter names are specified statically as a literal or constant, causes an exception that can be handled if an incorrect parameter name was specified. This only applies to function modules that are not called via Remote Function Call. In non-Unicode programs, an incorrect name was previously ignored.

See this links....

http://help.sap.com/saphelp_nw04/helpdata/en/79/c5546db3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c55470b3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c55473b3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c55476b3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c5547cb3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c5547fb3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c55482b3dc11d5993800508b6b8b11/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/79/c55485b3dc11d5993800508b6b8b11/content.htm

Plzz Reward if it is useful,

Mahi.