cancel
Showing results for 
Search instead for 
Did you mean: 

Upgrade 4.6C to ECC 6.0

david_torresllorente
Participant
0 Kudos

Hello,

I want tio know if it's necesary to convert the upgrade from noUNICODE to UNICODE or I can leave the Upgrade to UNICODE.

PM

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

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

1. Bit Statements

2. Adding Field Sequences

3. Loops with VARY and VARYING

4. Creating Subroutines

5. Saving Programs

6. Assigning Types for GET/SET PARAMETER

7. Unreachable Statements

8. Function Modules with Incorrect Parameter Names

1. Bit Statements

Previously, 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 Sequences

When 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 ].

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

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

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

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

ADD n1 FROM i1 GIVING m [ RANGE str ].

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

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

3. Loops

Loops 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:

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

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

3. 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 Subroutines

When 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 Programs

When 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:

1. A Unicode program creates a Unicode program.

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

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

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

6. Assigning Types for GET/SET PARAMETER

For 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 Statements

In 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 Names

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

http://service.sap.com/instguides

--> SAP Business Suite Applications

--> SAP ERP

--> mySAP ERP 2005

--> Upgrade

--> Upgrade Documentation - mySAP ERP 2005 SR2

There choose your database and operating system.

If you're looking for functional details check

http://service.sap.com/releasenotes

Answers (3)

Answers (3)

former_member4251
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi David,

The question has been relocated in the Migration to ERP2005 forum for expert assistance.

Thanks and Best Regards,

SDN Moderators Team!

david_torresllorente
Participant
0 Kudos

But Can I do the upgrade to ECC 6.0 with noUNICODE and then do the convertion???

I have read the document CU & UC (Combined Upgrade & Unicode Convertion) and I lost myself. I didn't kow where the PREPARE or the upgrade itself began.

Former Member
0 Kudos

Hi David,

You have to do the Upgrade first and then Unicode conversion as mentioned in CU&UC upgrade manual. the steps will be like, start with the prepare. After Prepare you start transaction SPUM4 and do all neccesary checks as mentioned in the CU&UC manual. then start the main upgrade including SPAU.

Now you need to do the UCCHECK as there might be many customized reports which will need to undergo some changes, UCCHECK will give you the list of reports and details.

Then do the Unicode conversion, means export and import according to SystemCopyGuide.

Do revert for any quiries.

Best Regards,

Sachin.

Former Member
0 Kudos

Hi,

Can someone please clarify if we can

-First, upgrade 4.6c SAP R/3 to ECC 6.0 Unicode software, while at the same time keeping the underlying Oracle database NON-UNICODE database

-Second at a later database, migrate the Oracle database to unicode as well?

Thanks,

Arul

markus_doehr2
Active Contributor
0 Kudos

> Hi,

> Can someone please clarify if we can

> -First, upgrade 4.6c SAP R/3 to ECC 6.0 Unicode

> software, while at the same time keeping the

> underlying Oracle database NON-UNICODE database

> -Second at a later database, migrate the Oracle

> database to unicode as well?

No.

If you read the Unicode upgrade guide you will see, that you need to "delete" the current database and recreate it again as Unicode database and import the export done after the upgrade.

--

Markus

MichaelTe
Contributor
0 Kudos

Hello David,

if your source system is 4.6C NON Unicode you can upgrade to ECC 6.0 NON Unicode.

If your source system is 4.6C Unicode you can upgrade to ECC 6.0 Unicode.

It is not possible to do the Unicode Conversion together with the Upgrade. So the following way won't work:

4.6C NON Unicode to ECC 6.0 UNICODE

You have to do the Unicode Conversion seperatly. But I am not sure if it is better to do the Conversion befor or after the Upgrade.

Hope that helps, Michael

Former Member
0 Kudos

as there is no 4.6C UNICODE at all, you will have first to upgrade to ECC6 non unicode and then perform the Unicode Migration.

Peter

Former Member
0 Kudos

HI,

If youre 4.6c is non unicode you can minimize down time by doing the prep steps for unicode conversion to gether with the upgrade. Of course you still have to do the unicode conversion but on teched there where some presentations where they showed scenarios on how you could minimize down time for both the upgrade and unicode conversion to gether.

Lando

MichaelTe
Contributor
0 Kudos

Hello,

right. My fault. In the SAP Service Marketplace there is a lot of documentation about this topic.

Look at <a href="http://service.sap.com/unicode">Unicode Information</a>

Regards, Michael