ECC6 Additions/drop off

[former_member194669]

Hi,

Please give info related to

1. What are new addtions (new functionality) given in ECC compared to 4.6c

2. What are functionalities in 4.6C will not work in ECC6

Please do not suggest to go thru Release Notes of ECC6

Thanks

a®

[RichHeilman]

Well, the new functionality introduced between those releases is quite extensive, the entire basis layer has been overhauled and transformed into what we now call NetWeaver, in the case of ECC 6.0, it is NetWeaver 7.0 ABAP Stack. Here are just some of the additions from 46c release.

NetWeaver is a full web server including HTTP, SMTP

Web Development using Business Server Pages(BSPs)

Support for exposing and consuming Web Services

Adobe Interactive Forms

Shared Memory Objects

Persistant Objects

ABAP Unit

Web Dynpro for ABAP

New ABAP Editor

New Debugger

Most likely, no functionality or features have been taken away, some just changed or enhanced.

As you may notice, allow of the new features and outlined in this new book from SAP-Press. (and yes, this is a shameless plug )

http://www.sap-press.de/katalog/buecher/titel/gp/titelID-1471?GalileoSession=57495312A3-i-.4LE40

http://www.sap-press.com/product.cfm?account=&product=H1986

Regards,

Rich Heilman

[Former Member]

ECC6 Additions followed by unicode.

ABAP Development under Unicode ecc 5. 6.0..

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.

[Former Member]

ecc 6.0 rules

Unicode Glossary

byte type

The ABAP data types X and XSTRING

character

Letter, digit, or special character

character-type

The ABAP data types C, N, D, T, and STRING

code

Binary encoding of letters, digits, and special characters

codepage

Set of encoded characters for the environment selected

data cluster

Grouping of several data objects (fields, structure, table)

DDIC

ABAP Data Dictionary

endian

The byte order of a number. Numbers are stored in memory with decreasing place value either from left to right (big-endian format) or from right to left (little-endian format)

front end

Presentation server in the R/3 System

kernel

The Basis functions of the R/3 System (written in C and C++)

NUP

Non-Unicode program: ABAP program for which the Unicode flag has not been set

NUS

Non-Unicode system: R/3 System, in which each character is encoded in binary form such that it occupies one byte

remaining length

Pertaining to a field or other character type structure, the total length minus the offset

surrogate area

Character supplement for characters that cannot be contained in standard Unicode (which can only contain 65,536 characters). In addition to the standard Unicode bit pattern, the system reads two further bytes from this area.

Unicode Fragment View

View that splits structures into similar data areas

UP

Unicode program: ABAP program for which the Unicode flag has been set

US

Unicode system: R/3-System, in which each character is encoded in binary form, such that it occupies either two or four bytes

UTF-8

Data format for communication and data exchange

XML

Extensible Markup Language: language used to display documents on the Internet

Valid Characters

In a US, all ABAP program sources are also stored as Unicode. As in ABAP Objects, you may only use the following characters as identifiers in programs for which the Unicode flag is set:

Letters a - z and A - Z without the German 'umlauts'

Numbers 0 - 9

The underscore _

For compatibility reasons, the characters %, $, ?, -, #, * and / are also permitted. You should, however, use them only in exceptional cases where you cannot avoid them.

To ensure that programs can be transported from a US to a NUS without any loss of information in the process of conversion, you should not use any characters for comments and literals even in a US that cannot be represented in an NUS.

Unicode Fragment View

The data layout of structures is relevant to UP checks with regard to the reliability of assignments and comparisons, for example. This data layout is represented in the Unicode fragment view. The fragment view breaks down the structure into alignment gaps, in byte and character-type areas, and all other types such as P, I, F, strings, references or internal tables.

Juxtaposed character-type components of a structure except strings are internally combined into a group if no alignment gaps exist between these components. All possible alignment requirements for characters are considered. Juxtaposed byte type components are grouped together in the same way.

Example

BEGIN OF struc,

a(2) TYPE C,

b(4) TYPE N,

c TYPE D,

d TYPE T,

e TYPE F,

f(2) TYPE X,

g(4) TYPE X,

h(8) TYPE C,

i(8) TYPE C,

END OF struc.

Fragment 1: a, b, c, d

Fragment 2: Alignment gap between d and e

Fragment 3: e

Fragment 4: f, g

Fragment 5: Alignment gap between g and h

Fragment 6: h, i

Data Types

The data types that can be interpreted as character-type in a UP include:

C: Character (letters, numbers, special characters)

N: Numeric character (numbers)

😧 Date

T: Time

STRING: Character string

Character-type structures: Structures which either directly or in substructures contain only fields of types C, N, D or T

In an NUS, a character of this type has a length of 1 byte, and in a US a length corresponding to the length of one character on the relevant platform. The data type W is no longer supported.

Variables of the types X and XSTRING are called byte-type. The main characteristics of the different kinds of structures are:

Flat structures contain only fields of the elementary types C, N, D, T, F, I, P, and X, or structures containing these types.

Deep structures contain strings, internal tables and field or object references in addition to the elementary types.

Nested structures are structures that contain substructures as components.

Non-nested structures are structures that do not contain any substructures.

Character-Type and Numeric Operands

Previously, there was a rule in ABAP that flat structures as arguments of ABAP statements can also be used anywhere were type C single fields are expected. In Unicode programs, this is generally no longer possible. In Unicode programs, you can only use a structured field for a statement that only expects a single field if this field consists of character-type elementary types or purely character-type substructures. The structure is treated like a type C single field.

In comparison with non-Unicode systems, flat structures are now only regarded as character-type to a limited extent and fields of the type X or XSTRING are never regarded as character-type. Additionally, flat structures are now only seen as numeric if they are purely character-type. Examples of numeric arguments are offset or length specifications such as for READ TABLE ... INDEX i. The following are examples of character-type and non-character-type structures:

Character-type:

BEGIN OF struc1,

a(2) TYPE C,

n(6) TYPE N,

d TYPE D,

t TYPE T,

END OF struc.

Non-character-type:

BEGIN OF struc2,

a(2) TYPE C,

b(2) TYPE C,

x(1) TYPE X,

i TYPE I,

END OF struc.

Another example is a group change in the case of internal tables, caused by the keyword AT. In non-Unicode systems, type X fields to the right of the group key are treated as character-type and hence filled with an asterisk. The same type in a Unicode system, on the other hand, is filled with its initial value.

In the context of Structure Enhancements, you should note the categories used in the Dictionary.

ABAP Development Under Unicode

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 are recommended to follow the procedure below to make your programs US-compliant:

The UNICODE task in transaction SAMT performs first an NUS and then a US syntax check for a selected program set. For an overview of the syntax errors by systems, programs and authors, consult the following document in SAPNet: Alternatively, you can start the ABAP program RSUNISCAN_FINAL to determine the Unicode-relevant syntax errors for a single program.

Before you can set the Unicode flag in the NUS in the attributes of the program concerned, all syntax errors must be removed.

Having enabled the Unicode flag in the NUS, you can run the syntax check for this program. To display a maximum of 50 syntax errors simultaneously, choose Utilities -> Settings -> Editor in the ABAP Editor and select the corresponding checkbox.

Once all syntactical requirements are met in the NUS, you must test the program both in the NUS and US. The purpose of this test is to recognize any runtime errors and make sure that the results are correct in both systems. To rule out runtime errors in advance, you should always type field symbols and parameters so that any potential problems can be detected during the syntax check.

ABAP and Unicode

From Release 6.10, ABAP supports multi-byte coding for characters in Unicode. Prior to Release 6.10, ABAP used only character sets that were based on single-byte codes – such as ASCII and EBCDIC – or double-byte codes, such as SJIS and BIG5.

This switch to Unicode affects all statements where an explicit or implicit assumption is made about the internal length of a character. If you use these statements in a program that is designed to exploit the Unicode capabilities of the runtime environment, they must be checked and changed if necessary. Once a Unicode-enabled program has been changed accordingly, it behaves in the same way in both Unicode and non-Unicode systems. You can develop programs in a non-Unicode system (NUS) and then import them into a Unicode system (US). The following sections describe the conversions that are necessary:

Character Codes

ABAP Development Under Unicode

Concepts and Conventions

Restrictions in Unicode Programs

New ABAP Statements for Unicode

New Classes for Unicode

RFC and Unicode

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