ABAP - By Theme (1) Introduction to ABAP ABAP Portability The ABAP Programming Language ABAP syntax Syntax Conventions Comments ABAP Types and Objects Data Types - Overview ABAP Type Names Built-in Elementary Data types and Complex Data Types Numeric Types User-Defined Data Types Working with Complex Types Strings Typing Formal Parameters and Field Symbols Data Objects - Overview Visibility of Data Objects Changing Data Objects Named and Unnamed Data Objects Structure of Data Objects Static and Dynamic Data Objects Binding Data Objects to Formal Parameters and Field Symbols Validity Area For Data Objects in Events Alignment of Data Objects Byte Sequence Literals Use of Data Objects Changeable Data Objects Non-Changeable Data Objects Character-Type Data Objects Numeric Data Objects Byte-Type Data Objects Memory Required References Typed Data References TYPES ... TYPE REF TO DATA DATA ... TYPE REF TO DATA Basic Statements Data Types and Data Objects1

Types TYPES TYPES - Defining Simple Types TYPES - Defining a Structured Type TYPES - Defining an Internal Table Type INCLUDE TYPE TYPE-POOLS Data Objects DATA Simple Field Definition Defining a Structured Data Object Defining an Internal Table Defining a Common Data Area CREATE DATA Type Declaration for CREATE DATA Reference Object for for CREATE DATA Line Type for CREATE DATA Tylbe Key for CREATE DATA Creating a Reference to a Data Object INCLUDE STRUCTURE CONSTANTS STATICS LOCAL FIELDS TABLES NODES Finding Out the Attributes of Data Objects DESCRIBE FIELD DESCRIBE DISTANCE Process data Assigning Values MOVE MOVE-CORRESPONDING WRITE ... TO PACK UNPACK CONVERT DATE / INVERTED-DATE CLEAR FREE Numeric Operations2

COMPUTE: Arithmetic Operations ADD ADD-CORRESPONDING SUBTRACT SUBTRACT-CORRESPONDING DIVIDE DIVIDE-CORRESPONDING MULTIPLY MULTIPLY-CORRESPONDING Exceptions for COMPUTE Processing Byte Strings and Character Strings CONCATENATE SPLIT SHIFT CONDENSE TRANSLATE TRANSLATE: Additional Information CONVERT TEXT OVERLAY REPLACE Replacement by Pattern Replacement by Position FIND SEARCH Processing Individual Bits in Hexadecimal Fields SET BIT GET BIT COMPUTE: Bit Operations Type conversions User-specific Input/Output Conversions Field Symbols FIELD-SYMBOLS ASSIGN ASSIGN - Basic Form CASTING Addition TYPE Addition DECIMALS Addition RANGE Addition ASSIGN COMPONENT ASSIGN - Dereferenced Reference Variables3

ASSIGN INCREMENT ASSIGN LOCAL COPY ASSIGN - Dynamic ASSIGN - TABLES Work Areas ASSIGN - TABLES Work Areas in the Main Program Group Runtime Errors for ASSIGN UNASSIGN Logical Expressions Relational Operators for All Data Types String Relational Operators Byte Comparison Operation Relational Operators for Bit Masks Relational Operator: In Range (BETWEEN) Relational Operator: Has Initial Value (IS INITIAL) Relational Operators Field Symbol Assigned (IS ASSIGNED) Comparison Operator: Valid Reference (IS BOUND) Test for Existence of an Actual Parameter (IS REQUESTED) Test for Transfer of an Actual Parameter (IS SUPPLIED) Relational Operator: In Selection Criterion (IN) Controlling the Program Flow Conditional Switching IF ELSEIF ELSE ENDIF CASE WHEN ENDCASE ON CHANGE OF ENDON Loops DO ENDDO WHILE ENDWHILE CHECK Continue EXIT (314)

4

Processing Large Datasets (316) Internal tables Internal Tables - Overview Table Types Generic Table Types Standard Key for Internal Tables Key Definitions for Internal Tables Specifying the Key of an Unstructured Internal Table Attributes of Objects as the Key of an Internal Table Change Individual Internal Table Rows Performance Notes for Internal Tables Internal Tables: Optimized Key Operations Statements Explicitly Specifying the Work Area Inserting and Deleting Table Entries in LOOPs Cost of Index Maintenance when Inserting and Deleting Rules for Locale-Specific Sorting Internal Tables - Keywords APPEND INSERT itab MODIFY itab COLLECT READ TABLE itab READ TABLE ... Output LOOP AT itab ENDLOOP AT - Control Level Processing SUM - Control Totals ENDAT DELETE itab REFRESH itab DESCRIBE TABLE EDITOR-CALL FOR itab SORT itab Extracts FIELD-GROUPS INSERT ... INTO EXTRACT LOOP SORT AT - Control Level Processing5

CNT - Control Break Counter SUM - Control Totals (425)

Saving Data Externally ..(427) Saving Data Objects as Clusters SAP Memory and ABAP Memory EXPORT TO MEMORY/DATABASE/SHARED BUFFER Runtime Errors for EXPORT TO DATABASE IMPORT FROM MEMORY/DATABASE/SHARED BUFFER Exceptions for IMPORT FROM DATABASE FREE MEMORY DELETE -Delete a Data Cluster Working With Files OPEN DATASET TRANSFER READ DATASET GET DATASET SET DATASET CLOSE DATASET DELETE DATASET Modularization Techniques Organization of Modularization Units Source code modules Macros DEFINE END-OF-DEFINITION Include Programs INCLUDE Procedures Literals as Actual Parameters for Typed Formal Parameters Subroutines FORM ENDFORM PERFORM Function modules Interfaces of Function Modules6

FUNCTION ENDFUNCTION CALL FUNCTION CALL CUSTOMER-FUNCTION RAISE Methods Special Topics The SAP Authorization Concept AUTHORITY-CHECK Exception Handling Class-Based Exceptions TRY CATCH CLEANUP ENDTRY RAISE EXCEPTION RAISING Addition for Procedures Exception Texts Exceptions in ABAP Statements Exception Classes for ABAP Statements Catchable Runtime Errors CATCH SYSTEM-EXCEPTIONS ENDCATCH Alphabetical Overview of Catchable Runtime Errors Assignment of Catchable Runtime Errors to Exception Groups Runtime Errors Debugging ASSERT BREAK-POINT GET RUN TIME SET RUN TIME CLOCK RESOLUTION SET RUN TIME ANALYZER Standardized Microseconds Link to Performance Notes SET EXTENDED CHECK SYNTAX-TRACE Time Stamp Converting Time Stamps GET TIME STAMP FIELD f CONVERT ... TIME STAMP ...7

GET TIME Setting the Language Key SET LANGUAGE SET LOCALE GET LOCALE Dynamic Program Processing Program INSERT REPORT READ REPORT DELETE REPORT EDITOR-CALL FOR REPORT SYNTAX-CHECK FOR itab GENERATE REPORT/SUBROUTINE POOL LOAD REPORT SCAN Text elements INSERT TEXTPOOL READ TEXTPOOL DELETE TEXTPOOL Screen EXPORT DYNPRO IMPORT DYNPRO DELETE DYNPRO SYNTAX-CHECK FOR DYNPRO GENERATE DYNPRO Special Statements for Applications INFOTYPES PROVIDE ENDPROVIDE (741)

ABAP User Dialogs (742) Screens Screen Flow Logic Statements8

PROCESS FIELD MODULE MODULE ... ON ... SELECT Values CHAIN ENDCHAIN LOOP ENDLOOP CALL SUBSCREEN ABAP Statements for Screens Modifying Screens using the SCREEN Table LOOP AT SCREEN MODIFY SCREEN SET HOLD DATA SUPPRESS DIALOG EXIT FROM STEP-LOOP CONTROLS CONTROLS ... TYPE TABSTRIP CONTROLS ... TYPE TABLEVIEW REFRESH CONTROL SET PF-STATUS GET PF-STATUS SET TITLEBAR SET CURSOR GET CURSOR Selection Screens PARAMETERS RANGES SELECT-OPTIONS SELECTION-SCREEN SELECTION-SCREEN: Defining Selection Screens SELECTION-SCREENS: Designing Selection Screens SELECTION-SCREEN: Formatting on Selection Screens SELECTION-SCREEN INCLUDE SELECTION-SCREEN: Special Variants for Logical Databases SELECTION-SCREEN: Special Variants for Logical Databases CALL SELECTION SCREEN AT SELECTION-SCREEN9

Modification Groups on Selection Screens Definition of Titles and Texts on Selection Screens Dynamic Selections Dynamic Selections on Selection Screens Dynamic Calls Lists LEAVE TO LIST-PROCESSING LEAVE LIST-PROCESSING Creating and Processing Lists Creating Simple Lists WRITE Predefined Output Formats WRITE - Formatting Options WRITE ... AS CHECKBOX WRITE ... AS SYMBOL WRITE ... AS ICON WRITE ... AS LINE ULINE SKIP NEW-LINE NEW-PAGE TOP-OF-PAGE END-OF-PAGE SET BLANK LINES Using Values Greater Than 255 With LINE-SIZE in Lists. System Fields for Lists Notes on the Use of LINE-COUNT Creating Complex Lists FORMAT DETAILS SUMMARY RESERVE POSITION BACK SCROLL SET LEFT SCROLL BOUNDARY SET COUNTRY Creating Interactive Lists HIDE AT LINE-SELECTION, AT USER-COMMAND, AT PFn10

WINDOW READ LINE MODIFY LINE SET USER-COMMAND DESCRIBE LIST Printing Lists General Information on Printing NEW-PAGE PRINT ON NEW-PAGE PRINT ON (Obsolete Additions) NEW-PAGE PRINT OFF SET MARGIN PRINT-CONTROL SUBMIT TO SAP-SPOOL Messages MESSAGE

ABAP Program Execution ..(1002) Processing blocks LOAD-OF-PROGRAM INITIALIZATION START-OF-SELECTION GET END-OF-SELECTION MODULE ENDMODULE CHECK REJECT STOP RETURN Introductory Statements for Programs PROGRAM REPORT FUNCTION-POOL11

CLASS-POOL INTERFACE-POOL TYPE-POOL Screen Sequences CALL SCREEN SET SCREEN LEAVE SCREEN LEAVE TO SCREEN Starting programs Calling an Executable Program SUBMIT Passing Parameters in SUBMIT Calling a Transaction CALL TRANSACTION LEAVE TO TRANSACTION Dialog modules CALL DIALOG Passing Data Using SPA/GPA Parameters SET PARAMETER GET PARAMETER Leaving a Called Program LEAVE PROGRAM LEAVE ..(1058)

ABAP Database Accesses .(1060) Relational Databases Open SQL SELECT12

SELECT Clause INTO Clause FROM Clause WHERE clause GROUP-BY Clause HAVING Clause ORDER-BY Clause ENDSELECT Subquery INSERT UPDATE MODIFY DELETE OPEN CURSOR FETCH CLOSE CURSOR Exceptions in OPEN SQL Dynamic Source Text in Open SQL Logical Condition in Database Access Statements Dynamic Logical Condition in Open SQL Field Label Column Reference Aggregate Functions Strings in Database Tables Secondary Database Connections Structure of Database Tables Performance Tips for Open SQL Programming Indexes Native SQL EXEC SQL ENDEXEC EXIT FROM SQL Logical databases Naming Conventions for Logical Databases PUT dbtab Contexts CONTEXTS SUPPLY DEMAND Contexts - Buffering Concept13

Transaction Processing Database Integrity Logical Unit of Work (LUW) Locking Database Locking SAP Locking Locking Conflicts During Database Read Access COMMIT WORK ROLLBACK WORK CALL FUNCTION ... IN UPDATE TASK SET UPDATE TASK LOCAL (1243)

ABAP Objects (1245) ABAP Objects - Overview Defining Classes and Interfaces Classes Class components Visibility Sections in Classes Attributes Methods Interface Parameters in Methods C Destructor Kernel Methods Constructors Visibility of Instance Constructors Events Types and Constants in Classes Inheritance Redefining Methods Abstract and Final Methods in Classes References to Subclasses and Polymorphism Inheritance and Interfaces14

Component Visibility Namespace of Components Inheritance and Static Attributes Inheritance and Constructors Inheritance and Instance Generation Interfaces Nested Interfaces Friends Objects Object references Accessing Class Components Accessing Attributes by References in Internal Tables Operators in ABAP Objects Statements in ABAP Objects Statements for Defining Classes and Interfaces Statements for Implementing Methods Statements in Class and Interface Pools Replacement of Obsolete Statements in ABAP Objects Incorrect Syntax Type Definitions and Data Declarations Assignments Offset/Length Specifications Character String Processing Field Symbols Logical Expressions and Control Structures Internal tables Procedures Data Cluster Program Calls Database accesses Lists Reporting ABAP Objects - Keywords CLASS PUBLIC SECTION PROTECTED SECTION PRIVATE SECTION ENDCLASS CLASS-DATA CLASS-METHODS15

CLASS-EVENTS METHODS EVENTS INTERFACES ALIASES METHOD ENDMETHOD INTERFACE ENDINTERFACE CREATE OBJECT CALL METHOD RAISE EVENT SET HANDLER Special Variants of Other Keywords TYPES ... REF TO cif DATA ... REF TO cif DATA ... READ-ONLY MOVE METH( ... ) TO ... MOVE ... ?TO ... COMPUTE ... ?= ... ABAP System Classes Classes for Determining Type Attributes at Runtime Classes for Character Set and Number Format Conversion Class for Mathematical Operations Class for Calculating with Time Stamps Classes for Specifying Field Attributes Classes for Data Clusters Class To Get Transaction Status ABAP - Object Services Persistence Service Transaction Service .(1478)

ABAP Unicode ..(1480) Constraints in Unicode Programs16

Names and Declarations Access with Offset and Length Assignments Handling Structures like a Single Component Comparisons Casting Field Symbols Type Checks and Type Compatibility Structure Typing Compatibility Byte String and Character String Processing Determine Length and Distance Key Entries for Table Accesses Storage of Cluster Tables in Database Tables File interface Database operations Structure Enhancements Other Changes Special Statements for Unicode Programs String Processing for Byte Sequences Determine Length and Distance Assignments to Field Symbols Offset/Length Accesses with Group Names Data Object Generation Dynamic Field Assignments Storage of Cluster Tables File interface .(1523)

ABAP Data and Communication Interfaces .(1525) Batch input Cross-Transaction Application Buffer CPIC COMMUNICATION RFC - Remote Function Call CALL FUNCTION ... DESTINATION (synchronous RFC) CALL FUNCTION ... IN BACKGROUND TASK (transactional RFC) CALL FUNCTION ... STARTING NEW TASK (asynchronous RFC) RECEIVE RESULTS FROM FUNCTION (asynchronous RFC)17

WAIT UNTIL logexp (asynchronous RFC) Define Remote Destinations (RFC) RFC Logon in Target System (Remote Logon) Trusted/Trusting Systems (RFC) RFC Authorization Concept Typical RFC Problems with Solutions OLE2 Automation CREATE OBJECT SET PROPERTY GET PROPERTY CALL METHOD FREE OBJECT CALL cfunc CALL TRANSFORMATION .(1607)

ABAP and JavaScript .(1612) Classes in JavaScript ..(1612)

ABAP - Overview Diagrams ..(1613) Alphabetical Overview of ABAP ABAP and Unicode ABAP System Fields Classification of Key Words by Type Example Programs Obsolete Keywords Obsolete Variants of the READ Statement

ABAP - Tools ..(1647) ABAP - Workbench Tools ABAP - Runtime Tools

18

ABAP Changes by Release .(1648) Changes Before Release 3.0 Changes in Release 3.0 Declarative statements RFC - Remote Function Call Logical Databases and Selection Screens String Processing Internationalization List Processing Debugger Arithmetic Expressions Assigning Types to Formal Parameters Displaying Icons on Screens OLE2 Automation Controller Open SQL Messages Miscellaneous Changes in Release 4.0 and 4.5 Catchable Runtime Errors Bit Operations and Bit Comparisons Data Types in the ABAP Dictionary Processing Large Datasets Extended Field Symbol Concept: Internal Tables - Key Tables Internal Tables and Extracts Runtime Analysis Open SQL RFC - Remote Function Call Selection Screens Logical Databases Time Stamp Additional Changes in Release 4.0 Additional Changes in Release 4.5 Introduction of ABAP Objects Runtime Analysis Changes in Release 4.6A19

ABAP Objects - Inheritance and Nested Interfaces ABAP Objects - Dynamic Method Call ABAP Objects - Other Developments ABAP Objects - Obsolete Statements New Data Types STRING and XSTRING Data Objects and Data References Data and Object Type Description at Runtime Named Includes Casting Arbitrary Data Types Dynamic Offset and Length Access Internal Tables Runtime Analysis Debugger Other Developments Other Changes Changes in Release 4.6C ABAP Objects Optimizations in the Runtime System Runtime Analysis Other Changes Changes in Release 6.10 Unicode ABAP Objects Object Services Internal Tables Character Strings File interface Compiler Runtime and Load Size Type Concept SQL and Updates Exception Handling Data References Using JavaScript with ABAP Debugger Coverage Analyzer List Processing System Fields Other Changes Changes in Release 6.2020

ABAP Objects Structure Enhancements Exceptions that Can Be Handled Extras Short Dumps Tools Other Changes.(1814)

21

ABAP - By ThemeABAP Programming This documentation describes the syntax and meaning of ABAP (Advanced Business Application Programming) key words. For more information on the concepts underlying ABAP programming in the R/3 System, see the following topic in the application help: BC ABAP Programming For executable example programs, see: Library of Examples

Introduction to ABAPABAP Introduction An introduction to the R/3 Basis System and the ABAP programming language is available in the SAP Library: ABAP Basics

ABAP PortabilityNotes on the Portability of ABAP The nature of SAP Basis software guarantees that ABAP programs can be supported by many different systems. There are only a few cases where transfer of programs to other platforms could cause problems. Native SQL Database-specific statements enclosed by EXEC SQL and ENDEXEC are the most critical factor for portability. Whenever possible, you should use ABAP/4 Open SQL. Files A parameter of the OPEN, CLOSE, TRANSFER, READ DATASET and DELETE DATASET statements is a file name which is passed to the underlying operating system. However, the organization of file systems (flat, hierarchical, ...) and the form of valid file names depends to a great extent on the operating system.22

The function module FILE_GET_NAME allows you to convert logical file names (platform-independent) to physical file names (platform-specific).

Numeric format The format of numeric types I and F can be represented by various byte sequences. With type F, even the code is different. Here, support is provided by the TRANSLATE ... NUMBER FORMAT command. Numbers While numbers of type P and I are treated in the same way on all platforms supported by SAP, there are differences with floating point numbers (type F). Although the value range (about 10**(-308) to 10**(+308)) and accuracy up to 15 decimal places is the same everywhere, rounding behavior can vary. These differences should not have any serious consequences in practice, but it is not advisable to test two floating point numbers for equality, with the exception of zero; instead, check that the difference is only very small as shown below. DATA: F TYPE F, G TYPE F, REL_DIFF TYPE F, EPSILON TYPE F VALUE '1E-6'. REL_DIFF = ABS( ( F - G ) / G ). IF REL_DIFF < EPSILON. ... ENDIF. Alignment Certain fields are aligned at the half word or word limit in field strings. As a result, these field strings may contain leading bytes, even before the first field. Furthermore, some ABAP/4 types are different, depending on the platform. For this reason, you should always address components of a field string by name and not with an offset value, i.e. T000-ORT01 rather than T000+28. Character set

23

The set of available characters and their coding depends not only on the platform, but also on the country and language of installation. The TRANSLATE ... CODE PAGE command allows you to convert texts from one coding to another. Sorting You can only make very limited assumptions about the effect of sorting on the character sequence. For instance:

Lower case letters can come before upper case letters or vice-versa. Numbers can come before letters or vice-versa. While the numbers 0 to 9 follow each other with no gaps, this is not necessary for letters. Letters with an accent are not sorted.

These problems affect the SORT, READ TABLE ... BINARY SEARCH and SELECT ... ORDER BY statements, as well as the comparison operators =, BT and NB. Unfortunately, there is no general solution at present. There is a special solution for the SORT statement. This is "locale" sorting, using the AS TEXT addition.

The ABAP Programming LanguageABAP Programming Language This section describes the ABAP programming language. For further information refer to The ABAP Programming Language in the SAP Library.

ABAP syntaxABAP Syntax This section contains notes on ABAP syntax. For more information, see also: ABAP Syntax

24

Syntax ConventionsSyntax conventions in the ABAP keyword documentation The ABAP keyword documentation uses the following syntax conventions:

Keywords and additions are written in uppercase. Example: APPEND, NON-UNIQUE, INTO, ...

Placeholders and other non-keywords are written in lowercase. Example: obj, linetype, tabkind, ...

Alternatives are separated by vertical lines and are enclosed in brackets or braces. Optional arguments are enclosed in brackets. If there are several options, all symbols until the next vertical line or closing bracket are to be regarded as a single option. Example: [WITH HEADER LINE]

Selection lists are enclosed in brackes. You must use one element from the list. The list must contain at least two options. Example: {UNIQUE|NON-UNIQUE}

CommentsComments in ABAP/4 Programs To make programs more readable and easier to maintain, they should always contain comments which describe the effect of certain statements at the relevant places. There are two types of comments in ABAP/4 programs:

25

The whole line is considered to be a comment if there is an asterisk (*) in the first column. These comments are highlighted in a different color in the editor. Any part of a line beginning with a quotation mark (") is also a comment. However, this applies only if the quotation mark is not itself within a character-type literal. Such literals always begin and end with quotation marks (').

Introducing blank lines at strategic points can also improve the readability of programs.

ABAP Types and ObjectsABAP Types and Objects In ABAP we have to distinguish between types and objects. While types are simple descriptions that do not use storage, objects are instances of types using storage. A type specifies the technical properties of all objects of that type. The ABAP types make up the ABAP type hierarchy: Hierarchy of ABAP Types Types ---- Data types ---- Elementary ---- Fixed length--- C | | | |-- N | | | |-- D | | | |-- T | | | | | | | |-- X | | | | | | | |-- P | | | |-- I | | | |-- F | | | | | |-- Var. length--- STRING | | |-- XSTRING | |-- Reference types | | | |-- Complex ---- Structured | |-- Table type |26

|-- Object types --- Classes |-- Interfaces We basically distinguish between data types and object types.

Data types describe data objects. They are further subdivided into elementary, reference, and complex types. There are built-in (predefined) data types, and they can be defined locally in the program or system-wide in the R/3 Repository. Object types describe objects in ABAP Objects. They are further subdivided into classes and interfaces. Object types contain the above data types on the one hand, but also functions on the other hand. Object types are not built-in, but must be defined in the program or in the R/3 Repository. Classes describe an object completely. They define which data types and which functions an object contains. Interfaces describe a partial aspect of an object. The data types and functions of an interface can be implemented by several classes.

The hierarchy of the ABAP objects reflects the ABAP type hierarchy: Hierarchy of ABAP objects Instances ---- Data objects ---- Elementary ---- Static ---- C | | | |-- N | | | |-- D | | | |-- T | | | | | | | |-- X | | | | | | | |-- P | | | |-- I | | | |-- F | | | | | |-- Dynamic ---- STRING | | |-- XSTRING | |-- Reference variables | | | |-- Complex ---- Structures | |-- Internal tables | |-- Objects Objects as instances of ABAP types are divided into the following two categories:27

Data objects are fields in the proper sense of the word. They contain the data local in the program used by the program at runtime. Objects are genuine software objects in ABAP Objects and support objectoriented programming because they contain not only data but also methods and events.

Data Types - OverviewData Types Data types are mere type descriptions with no memory involved. A data type characterizes the technical properties of all data objects that have this type. Data types occur as attributes of data objects but can also be defined independently. The definition of independent data types builds on a set of predefined data types. It can be included in the declaration part of a program using the statements TYPES or defined generally in the ABAP Dictionary. Independent data types can be used to declare data objects and for type checks in generic operations. Data types are a subtree of the ABAP type hierarchy: Hierarchy of ABAP data types Data types ---- elementary ----fixed length---- C | | |-- N | | |-- D | | |-- T | | | | | |-- X | | | | | |-- P | | |-- I | | |-- F | | | |-- var.length ---- STRING | |-- XSTRING |-- reference types | |-- complex ---- structured Data types are subdivided into elementary types, reference types, and complex types.

28

Elementary types are atomic, that is they are not a combination of other types. They are subdivided into fixed-length and variable length types.o

ABAP includes eight built-in elementary data types with fixed length:

a. four character-type types: character fields (C), numeric character fields (N), date fields (D), time fields (T) b. X for byte fields with hexadecimal display c. three numeric types: integer (I), floating-point numbers (F), and packed numbers (P)o

ABAP includes two variable-length elementary types:

a. STRING for character strings b. XSTRING for byte sequences

Reference types describe data objects that include references to other objects (data objects and objects from ABAP Objects). Reference types form a hierarchy that represents the hierarchy of the objects to which the references point. Complex types are combined of other types. They make it possible to manage and process semantically related data sets under one name. Complex-type data objects can be accessed as a whole or by component. ABAP does not have any built-in complex data types. A complex data type must either be defined in an ABAP program or in the ABAP dictionary. Complex data types are subdivided into structures and internal tables.o

A structure (record) is a sequence of any elementary, reference, or complex data types. Structures are used in ABAP programs to combine work areas that are logically related. Since the individual structure elements can have any data type, structures can be used in many different ways. Internal tables consist of a sequence of lines with the same data type. Tables are characterized by:

o

a. the line type, which can be any elementary data type, a reference type or complex data type b. a key to identify the table lines. It can be built up from the elementary fields of the lines. Distinction is made between unique and non-unique keys. c. the access type that defines how ABAP accesses the table. With respect to the access type, distinction is made between sorted and unsorted index tables and

29

hash tables. Internal tables are always used when multiple data of a fixed structure are used within the program. For further information refer to Data Types in the SAP Library.

ABAP Type NamesABAP Type Names Every explicit type, that is, all types defined in the ABAP Dictionary or or in the ABAP source code using TYPES command, has a relative type name and an absolute type name. Implicit types are created when, at the DATA command in the TYPE specification, a new type is derived from an existing one, for example, using REF TO or LINE OF. These implicit types do not have a relative type name but the system generates a technical absolute type name. Technical absolute type names are assigned as long as the program, in which the type is located, is not changed. Example TYPES: my_ref_type TYPE REF TO c01. DATA: ref1 TYPE my_ref_type, ref2 TYPE REF TO c01. The variable REF1 was created with an explicit type, that is, the type of the variable REF1 has the type name MY_REF_TYPE. The variable REF2 was created with a type which was first implicitly constructed in the DATA statement. This means that the type of variable REF2 does not have a type name. Relative Type Names Relative type names are not unique. The point in the program, at which type is used, defines which type is meant. Each type name assigned in the Dictionary or in the TYPES statement is a relative type name. Absolute Type Names Absolute type names are unique within a system. It is not important in which area the type name is used. The name always points to the same type. This prevents30

types from being hidden by other types. Absolute type names can only be specified dynamically. This means you can use them only for those statements supporting the dynamic variant of the TYPE addition. Unlike relative type names, absolute type names contain additional information about the context in which the type was defined. For this purpose, absolute type names are subdivided into sections (tags), similarly to the path of file names. The individual tags are separated by a backslash (\). An absolute type name always begins with a backslash. The following tags are allowed:

\TYPE=name \CLASS=name \INTERFACE=name \PROGRAM=name \CLASS-POOL=name \FUNCTION-POOL=name \TYPE-POOL=name \METHOD=name \FORM=name \FUNCTION=name

Absolute type names always end with one of the following three tags:

\TYPE=name \CLASS=name

for data types for classes

\INTERFACE=name for interfaces

If an absolute type name consists of only one of these three tags, it is a global type (Dictionary), a global class, or a global interface. Example PROGRAM my_program. ...31

TYPES my_type TYPE i. ... CLASS my_class DEFINITION. PUBLIC SECTION. METHODS my_method. ENDCLASS. ... CLASS my_class IMPLEMENTATION. METHOD my_method. TYPES my_type TYPE f. ... ENDMETHOD. ENDCLASS. Two types were defined in this program. Both types have the relative type name MY_TYPE. The point in the program where the type is used defines which type is referred However, both types have a different absolute type name:

\PROGRAM=MY_PROGRAM\TYPE=MY_TYPE for the type declared at the beginning of the program using TYPES my_type TYPE i. \PROGRAM=MY_PROGRAM\CLASS=MY_CLASS\METHOD=MY _METHOD\TYPE=MY_TYPE for the type declared within the method MY_METHOD using TYPES my_type TYPE f.

Both types can be uniquely identified in all areas of the program by the absolute type name.

Built-in Elementary Data types and Complex Data TypesBuilt-in elementary data types and complex data types ABAP contains a range of built-in elementary data types: Character (text), Numerical character (number string), Date, Time Integer, Floating point number, Packed number, and HeX code). Some of these data types are fully types (D, T, I, F), others (C, N, P, X) are generic, in the sense that you must provide further type information (length, for type p also the number of decimal places) when you create the data object (DATA).

32

In addition to the elementary data types C and X, which always refer to a fixedlength memory area (to be specified when the data objects are created), there are two corresponding data types with dynamic memory management. Their length is automatically adjusted to the requirements of the data object to be stored. These types are character strings ( STRING and) byte sequences (XSTRING). In addition to the elementary data types, ABAP provides two options to create complex data types:

By combining components of any type to form a structure (record). By using a line of any type to form an internal table.

You can use structures and internal tables to create both complex data types and directly to create complex data objects.

Numeric TypesABAP Numeric Types ABAP supports three numeric data types - I, P and F. Type N is a text type, not a numeric data type (although its values are strings of digits), because the strings are not used for calculation purposes. Typical examples of type N fields are account and article numbers (provided they contain only digits), as well as the sub-fields of date and time fields. Calculations involving type I or F fields correspond more or less directly to machine commands. In contrast, calculations involving packed numbers (type P) are programmed, and thus noticeably slower. Type I values are integers in the range +/- 2 billion, or, exactly, from -2147483648 to 2147483647. Intermediate results in type I expressions are stored in type I auxiliary fields. Otherwise, type I arithmetic is similar to performing calculations with type P fields without decimal places; division (using the operator /) rounds numbers rather than truncating them. Overflow results in a runtime error. Type I is typically used for counters, quantities, indexes and offsets such as time periods. The value range of type P fields depends on their length and the number of decimal places. P fields can be 1 to 16 bytes long, with two decimal digits packed into each byte, and one decimal digit and the sign packed into the last byte. There can be up to 14 decimal places. Auxiliary fields for intermediate results are always 16 bytes long and can thus hold up to 31 decimal digits. To ensure that the decimal point is correctly calculated, you should always set the program attribute "fixed point arithmetic". Otherwise, all numbers are specified as integers and all intermediate results for the next integer are rounded. If "fixed point arithmetic" is33

not set, the decimal places defined for the number only appear when outputting with WRITE. Fixed point arithmetic is decimal arithmetic and is similar to using a pocket calculator or calculating with paper and pencil. Type P is typically used for sizes, lengths, weights and sums of money. Rule: If you want to calculate "down to the last penny", you should use the type P. Type F values range from +/- 2.2250738585072014E-308 to 1.7976931348623157E+308, as well as the number 0, with an accuracy of at least 15 decimal places. You cannot enter floating point numbers directly in your programs. Instead, you must use text literals that can be interpreted as floating point numbers. You may use the following formats: Decimal numbers with or without sign, with or without decimal point. The form E, where the mantissa is a decimal. The exponent may be specified either with or without sign. You may also use spaces before or after the number. Examples of text literals with "floating point numbers": '1', '-12.34567', '-765E-04', '1234E5', '+12E+34', '+12.3E-4', '1E160'. Use floating point arithmetic if you need a very large value range or you are making decimal calculations, but be aware of the following features of floating point arithmetic. Internally, the exponent and the mantissa of floating point numbers are stored separately, each in two parts. This can lead to unexpected results, despite the high degree of intrinsic accuracy. These occur mainly when performing conversions from and to type F. For example, the number 1.5 can be represented exactly in this notation, since 1.5 = 1*2**0 + 1*2**(-1), but the number 0.15 can only be represented approximately by the number 0,14999999999999999. If you round 0.15 up to 1 valid digit, the result is 0.1 rather than 0.2 as you would expect. On the other hand, the number 1.5E-12 is represented by the number 1.5000000000000001E-12, which would be rounded to 2E-12. Another example which actually occurred is the calculation of 7.27% of 73050 to an accuracy of 2 decimal places. The intermediate result 5.3107349999999997E+03, since the correct result, 5310.735, cannot be represented exactly in two parts with 53 bits. (If the hardware cannot represent a real number exactly, it uses the next representable floating point number. After rounding, you therefore get 5310.73 rather than 5310.74 as you would expect. The ABAP runtime system calculates commercially and not "numerically" like the underlying machine arithmetic. According to the rounding algorithm of the latter, the end digit 5 must always be rounded to the nearest even number (not the next largest number), i.e. from 2.5 to 2, 3.5 to 4. You should also note that multiplication using powers of 10 (positive or negative), is not an exact operation. For example, although 100.5 can be represented exactly34

in two parts, after the operation F = F / 100 * 100 F has the value 100.49999999999999. As well as rounding errors, the restricted number of decimal places for the mantissa can lead to the loss of trailing digits. For example, 1 1.0000000000000001 results in zero. This means that you cannot rely on the last digits in floating point arithmetic. In particular, you should not usually test two floating point numbers for equality; instead, you should check whether the relative difference abs((a - b)/a) is less than a predefined limit, e.g. 10**(-7).

User-Defined Data TypesUser-Defined Data Types User-defined data types allow you to define your own range of application-specific data types. You caon do this centrally, and thus make the types available throughout the ABAP programming environment. Local Types in Programs You can store user-defined types either locally in a program, or centrally in the ABAP Dictionary. The TYPES statement allows you to create local types in a program. Userdefined types can be either elementary or complex. The syntax of the TYPES statement is similar to that of the DATA statement that you use to declare data objects. You can use user-defined data types anywhere where you could use predefined data types, that is, to create data objects, or to specify the types of formal parameters and field symbols. Global Types Global types are stored in the ABAP Dictionary, either as elementary types (data elements), or as complex types, constructed from existing elementary data types. As well as "real" data types, the ABAP Dictionary still contains type groups, A type group is a segment of ABAP code that you maintain in the ABAP editor. Its first statement is TYPE-POOL. Type groups can contain definitions of both types and constants. The names of all of the types and constants in a type group must be prefixed by the name of the type group itself, followed by an underscore. To address types from a type group in a program, you must declare the gropu in the program using the TYPE-POOLS statement.35

Working with Complex TypesWorking with Complex Types Complex types can be made up of either elementary types or from other complex types. For example:

Structures can contain components of any type Internal tables can be defined from any line type

The fact that structures can contain components of any type means, in particular, that:

Structures can contain sub-structures (nested structures) Tables can be components of structures (deep structures)

The fact that internal tables can be defined using any line type allows you to create: Da interne Tabellen ber Zeilen beliebigen Typs definiert werden knnen, erlaubt insbesondere die Vereinbarung von

Tables of unstructured line types (dynamic arrays of elementary types) Tables of structures with tabular components (tables with a deep line type) Tables of tables

Complex data types allow you to model complex data objects. You can aggregate fields, structures, and internal tables in one declaration. The inner structure of the data object can be encapsulated so that interfaces can be more streamlined. Internal tables that are part of a complex data object never have a header. This allows you to define basic operations on any data object in an uncontrived way. Only internal tables at the top level of an object can (but need not) have a header.n aber nicht) eine Kopfzeile haben. If itab is an internal table with a header, you can address the table body using itab[]. Basic universal operations Complex data types and objects are integrated seamlessly in the ABAP language. SAP has defined a range of operations that can be performed on any data object.

36

The semantics for complex data objects are uncontrived because they are based on the equivalent operations on elementary objects. At present, the following ABAP statements have been defined for use with any data object:

MOVE: MOVE for structures entails a assignment component-by-component. MOVE for internal tables entails copying the content of the table (that is, "deep copy" as opposed to a "shallow copy").

Comparisons using:o o o

Logical expressions (IF, CHECK, WHILE), Sorting (SORT) and Control break processing (AT NEW / AT END OF, ON CHANGE OF):

Two structures are considered equal if each component is of the same type. A structure is considered smaller than another if it contains the first smaller component in the predefined component order. Two internal tables are considered equal if they have the same number of lines and are identical line-by-line in the predefined line order. A table is considered smaller than another if it has fewer lines, or if it has the same number of lines but contains the first smaller line in the predefined line order.

Reset to initial (CLEAR): For structures, CLEAR entails a component-by-component reset. For internal tables, it is the same as the REFRESH statement.

Passing parameters (FORM / PERFORM, FUNCTION / CALL FUNCTION): You can pass any data object using the USING and CHANGING parameters in the FORM / PERFORM statement, and by using IMPORTING and EXPORTING parameters in the FUNCTION / CALL FUNCTION statements.

Dynamic adressing (ASSIGN): Field symbols can point to any data object, particularly to an internal table.37

Exporting and importing (EXPORT / IMPORT):

You can use the EXPORT/IMPORT interface to store any data object (in main memory) on the database. Moreover, you can perform any of the following table operations on internal tables with any line type: (APPEND, COLLECT, INSERT, MODIFY, DELETE, REFRESH, FREE, READ, SORT, LOOP, AT NEW / AT END OF, SUM) .

StringsStrings - Fields with Variable Length The elementary data type STRING is similar to data type C and refers to a variable-length string. Accordingly, the elementary data type XSTRING is similar to data type X and refers to a variable-length byte sequence. In contrast to a C or X field, the length of a string is not static but variable and adjusts itself to the current field content at runtime. Dynamic memory management is used internally. Strings can have any length. The initial value of a string is an empty string with length 0. A structure containing a string is seen as deep. A deep structure cannot be used like a C field. Strings can be displayed in the ABAP Debugger and used in the ABAP Dictionary. It is not yet possible to use strings in screens or database tables. However, strings can be stored in database tables as clusters using EXPORT and transferred using IMPORT. Working with Strings

Typing Formal Parameters and Field Symbols

38

Typing Formal Parameters and Field Symbols Formal parameters in FORM and FUNCTION, and field symbols (FIELDSYMBOLS) may be typed in ABAP. To do so, you use the ... TYPE dataType or ... LIKE dataObject additions to specify a type. Typed formal parameters and field symbols make programs safer, and easier to understand and maintain. They also allow the ABAP generator to generate optimized intermediate code, thus improving the performance of your programs. If a formal paramter or field symbol is typed, the syntax check (if possible), or the runtime environment will check whether the actual parameter and formal parameter are compatible. Typing with Complete Types Compatibility in this context means that the two objects have the same technical type. Two types are compatible if they have exactly the same technical attributes. The technical attributes of a simple field are its elementary data type and the field length (in the case of type P fields, the number of decimal places as well). These are considered in the type check. The conversion exit and help ID are not. Note that the types STRING and C as well as XSTRING and X, are not compatible. In structures, the form of the structure is considered in addition to the component types. Two structures may have the same sequence of elementary components, but if that sequence is divided into substructures in different ways in the two structures, they are not compatible in the sense of the technical ABAP type check. Two internal tables are compatible if their line types are compatible. The OCCURS value is not considered in the type check. Typing with Generic Types A formal parameter or a field symbol can be typed incompletely by choosing a generic type which restricts the type of the actual parameter or runtime type to a subset of specific runtime types. Generic type specifications can be performed as follows. The type ANY allows all generic and elementary types. The following generic types make a restriction to the elementary runtime types.

SIMPLE: Allows all types which are permitted by the generic types CLIKE, XSEQUENCE, or NUMERIC CLIKE: Allows all types which are permitted by the generic types CSEQUENCE and N as well as the elementary types D and T and also structures which (directly or indirectly in substructures) contain only components of the types C, N, D, or T. In non-Unicode programs, the

39

generic type XSEQUENCE and all generic and elementary types contained therein are allowed additionally, and besides the components of the above structures, the types X and XSTRING are also allowed.

CSEQUENCE: Allows all types permitted by the generic type C as well as type STRING XSEQUENCE: Allows all types permitted by the generic type X as well as type XSTRING NUMERIC: Allows the generic type P, the elementary types I and F as well as the Data Dictionary types INT1 and INT2 C, N, X: Allows all types C, N, X with a length between 1 and 32767 P: Allows all types P with a length between 1 and 16 and with decimal places from 0 to 14

The following generic types make a restriction to the types of internal tables.

... TYPE TABLE allows you to mark a formal parameter or a field symbol as a table parameter or table symbol for any internal table. ... TYPE [ANY|INDEX|STANDARD|SORTED|HASHED] TABLE is used to accept tables of the table type specified which are compatible with the access hierarchy. The line type of the actual parameter can be chosen as required.

The following overview shows all ways of generic typing. +---I,INT2,INT1 +-----------NUMERIC-----+---P | +---F | | +---X +---SIMPLE---+-----------XSEQUENCE---+---XSTRING | | | +---CLIKE-+-CSEQUENCE---+---STRING ANY---+ | +---C | | | | +---N | +-------------+---D | +---T

40

| | +---TABLE

+---STRUC(C,N,D,T)

Other Comments on Typing with Generic Types If a formal parameter or a field symbol is not typed or not typed completely, the formal parameter inherits the type attributes of the actual parameter. However, if a complete typing was made, the formal parameter always has the type attributes specified through typing. In other words, this means that concerning the type attributes not considered by the type check (such as conversion exit and help ID) and which can therefore be different even for compatible actual and formal parameters,

the actual parameter takes priority in case of missing or incomplete typing, and the formal parameter takes priority in case of complete typing.

Data Objects - OverviewData Objects Data objects are instances of data types, that is the specific data that a program handles at runtime. Each data object has a specific data type and appropriate memory assigned to it. Data objects are instances of the data types subtree in the ABAP type hierarchy: Data objects ---- elementary ---- static | | |-- N | | |-- D | | |-- T | | | | | |-- X | | | | | |-- P | | |-- I | | |-- F41

---- C

| | | |-- dynamic ---- STRING | |-- XSTRING |-- reference variables | |-- complex ---- structures |-- internal tables Data objects are defined statically with a data defining statement or dynamically using an operational statement. The prototype data defining statement is DATA. In addition, several other statements are available to define data objects with additional specific properties. In addition to the data objects declared in the program, several data objects are introduced automatically, for example, the system fields SY-... or the constant SPACE. SUM(f) and CNT(f) within control level processing for extracts are also implicitly defined data objects. The technical properties of data objects - that is, the field length, number of decimal places, and the data type - are always defined uniquely at runtime. There are two main types of data objects: Static data objects , where all technical properties must be defined in the declaration; and dynamic data objects, where the memory requirements and size are determined at runtime. Dynamic data objects are the elementary data objects of types STRING and XSTRING and internal tables.

The length of character and byte strings is zero after their declaration; it changes during runtime according to the content assigned. Internal tables do not contain any lines after their declaration. They can have any number of lines and are filled dynamically at runtime.

All other data objects are static. For further information refer to Data Objects in the SAP Library.

Visibility of Data ObjectsVisibility of Data Objects

42

Data objects are always declared locally in a program. In terms of visibility, that is, their capacity to be addressed by name, a data object in ABAP can have local, global, or cross-program visibility.

Locally-visible data objects are created within a procedure (FORM or FUNCTION) using a declarative statement, and are visible within that procedure after the point at which they are defined. A locally-visible object with the same name as a globally-visible object will obscure the global object within the procedure. Globally-visible data objects are created within a program, that is, anywhere but in a procedure, using a declarative statement other than TABLES. They are visible within that program after the point at which they are defined (as long as they are not obscured in a procedure by a local data object with the same name). A data object has cross-program visibility if it is defined using TABLES or DATA ... COMMON PART in a program. It is visible globally within the program from the point at which it is defined. In this respect, it is the same as a globally-visible object. However, the object is also placed in the cross-program memory that is shared at runtime by all programs that contain a corresponding data defintion.

Changing Data ObjectsVariable and Constant Data Objects With respect to the changeability of data contents,distinction can be made between variable and constant data objects:

Variable data objects can change their value at runtime. All data objects that are not defined by a statement defining data CONSTANTS are variable. Constant data objects always retain their initial value. They include the literals and the constants declared by CONSTANTS

Named and Unnamed Data ObjectsNamed and Unnamed Data Objects

43

With regard to the symbolic addressability, you can distinguish between named and unnamed data objects:

Variables and constants are named data objects and as such can be addressed symbolically by name regardless of the value. Literals represent themselves, i.e. they are fully defined as unnamed data objects by their value.

Structure of Data ObjectsStructure of Data Objects The structure of a data object can be an

elementary field, a structure, or an internal table.

Structures and internal tables are complex data obejcts. Since it is possible to combine structures and internal tables in any way, we can can also make a general distinction between different types of structures, internal tables, and data structures. A structure can be:

A simple structure (as opposed to complex structures). A simple structure is a structure with elementary components. A nested structure. A nested structure is a structure containing one or more further structures. A deep structure. Deep structures are structures that contain an internal table as a component, either directly or indirectly).

An internal table can be:

A simple internal table (as opposed to complex internal tables). A simple internal table has a simple structure. A dynamic array of elemntary types. This is a table with a non-structured line type.

44

A table with a deep line tpye. This is an internal table whose line type contains one or more internal tables. Tables containing tables and tables with a deep structure are both examples of tables with a deep line type.

Data structures (that is, structures and internal tables), can be distinguished as follows:

Simple data structures (unlike complex data structures). These are simple structures or simple internal tables. Deep data structures. These are deep structures or internal tables.

Static and Dynamic Data ObjectsStatically-Declared and Dynamically-Created Data Objects There are two kinds of data objects: those that are declared statically,and those that are created dynamically.

Any data object that you declare using a declarative statement is statically declared, regardless of its visibility, validity and structure, whether or not it can be changed, or addressed symbolically. Statically-declared data objects are administered when the program is generated. The lines in an internal table are created dynamically by the APPEND, COLLECT, and INSERT statements. Data objects with type STRING and XSTRING are also dynamic. They have initial length when the are declared; the memory that they use is assigned dynamically. ASSIGN LOCAL COPY OF f TO allows you to create data objects dynamically on the stack.

Since the dynamic validity of local internal tables and dynamic stack extensions is restricted to the lifetime of the defining procedure, the corresponding resources are released automatically by the ABAP runtime system when the procedure ends. This means that you do not normally need to include memory management in your ABAP programs. However, you can release space occupied by an internal table using DELETE to delete individual lines, or REFRESH or FREE to delete a whole table.

45

Binding Data Objects to Formal Parameters and Field SymbolsBinding of Data Objects to Formal Parameters and Field Symbols Currently data objects are bound to the formal parameters in subroutines, function modules and methods at runtime. Bound formal parameters behave like locally visible variables with automatic validity. Data objects are also bound dynamically to FIELD-SYMBOLS. Bound field symbols behave like local or global variables, depending on whether the field symbol has been defined locally or globally.

Validity Area For Data Objects in EventsData Declarations in Events With "DATA X" in an event: When is X local, when is it global? When you declare data (for example, using DATA), it depends on where in the program you define it as to whether it is global (can be addressed anywhere in the program), or whether the scope is restricted to the event in which you have placed it (local). Whilst it is clear that DATA X between FORM and ENDFORM or FUNCTION and ENDFUNCTION defines a variable X that is only recognized within the routine, the handling of this issue is not so clear with events. In this case, it depends whether the event is implemented internally as a FORM routine or not. Global: INITIALIZATION START-OF-SELECTION END-OF-SELECTION TOP-OF-PAGE... MODULE Local: AT SELECTION-SCREEN... GET dbtab... Example46

Global data definition: INITIALIZATION. DATA X. START-OF-SELECTION. MOVE 'A' TO X. is syntactically correct. Example Local data definition: AT SELECTION-SCREEN. DATA X. START-OF-SELECTION. MOVE 'A' TO X. results in a syntax error because the field X is known only in connection with the event "AT SELECTION-SCREEN".

Alignment of Data ObjectsAlignment of Data Objects You cannot simply store fields at any addresses you want in main memory. For example, an ABAP field of the type I should normally have an address divisible by 4, a field of the type F an address divisible by 8, and so on. A field is considered to be aligned when it has an address corresponding to its data type. For components of a structure, the distance of the component from the beginning of the structure is known as the offset of the component. A structure is aligned if both the following are true:

Its start address satisfies the strictest alignment requirements of its components and The offsets of all components satisfy the same type-specific divisibility requirements.

Normally, ABAP programmers do not have to be concerned about the correct alignment of fields or structures because this is set automatically on declaration. In the following cases, however, you must pay attention to alignment:

47

When using ASSIGN to assign a new type to a field or structure When using PERFORM to pass a field or structure as a parameter to a FORM routine which expects a different type When an Open SQL command is used with a work area that has a different type to that of the database table.

Also, the offset of a structure component may not be the same as the total of the field lengths of the preceding components because some fields may be padded. If the alignment of a field or structure is insufficient, a runtime error occurs.

Byte SequenceByte Order Binary representation of numbers The binary representation of ABAP type I and type F numbers is hardwarespecific. The byte order, which is pre-defined by the processor, is important in this respect. The byte order determines whether the highest-value byte ("big endian" binary representation) or lowest-value byte ("little endian" binary representation) is stored first. Example You can represent the number 16909060 (in hexadecimal notation) as follows: Endian Byte 1 Byte 2 Byte 3 Byte 4 big 0x01 0x02 0x03 0x04 little 0x04 0x03 0x02 0x01 The most common processors are Intel and DEC Alpha, both of which use little endian. Most other processors use big endian. Binary representation of characters Characters are represented in the Unicode format UCS-2 using 2-byte unsigned integer values. This means that this format depends on the number representation used by the hardware. Thus you must differentiate between UCS-2BE (big endian) and UCS-2LE (little endian). Container problems

48

Character-type or byte-type data objects of the type c, string or x, xstring are often used as anonymous containers for data objects, especially structures, and stored persistently. If such a container is stored and imported on an application server with a different byte order, problems can arise if the container is used for contents for which the byte order is important. This is always the case when numeric content of the type i or f is stored in character-type or byte-type containers. In Unicode Systems further problems can arise when byte-type content is stored in character-type containers. Usually, to be able to work with the contents of an imported container, a casting is executed on the data type, whose data is stored in the container. However, because no type information is stored in the container, any necessary conversion of the byte order cannot take place. The only way to prevent these problems arising is to avoid having numeric components in anonymous containers and never store byte-type contents in character-type fields.

LiteralsLiterals There are two types of literals in the ABAP programming language: Character literals and numeric literals. Character Literals Character literals can be grouped into text field literals and string literals. Text Field Literals Text field literals are enclosed in single quotation marks (') and have the data type C. If the quotation mark occurs in the middle of the character string, it must be duplicated: 'AB''CD' An empty text field literal (''), that is, a literal that does not contain any characters is automatically set to a literal of length 1 with a blank as its content (' '). Since text field literals have the data type C, closing blanks such as in assignments and VALUE specifications are ignored. If one line is not sufficient, you can link several text field literals using the operator &.49

Examples: 1. 'ABCD' 2. 'AB' & 'CD' 3. 'AB' & 'CD' All three options designate the same literal. If a text field literal reaches the end of the line, it can be continued at the beginning of the next line. Since the editor converts the characters in the continuation line into upper case, you can only make restricted use of this feature. In ABAP Objects, that is in classes and class pools, the syntax check made here is stricter. See Cannot Process a Literal Over Several Lines. If a REPORT has lines containing more than 72 characters, cross-line literals cause an error during the syntax check if the last significant character is in the the first line right in the 72nd column. However, if the last significant character is in the first 72 columns, the syntax check, for compatibility reasons, only displays a warning. To ensure program safety it is better not to use cross-line literals, but instead construct long literals with the operator & (see above). String Literals String literals are enclosed in single back quotes (`) and have the data type STRING. If the back quote occurs in the middle of the character string, it must be duplicated: `AB``CD` An empty string literal (``), that is, a literal that does not contain any characters represents an empty string of zero length. Since string literals have the data type STRING, closing blanks such as in assignments and VALUE specifications are considered. If one line is not sufficient, you can link several string literals using the operator &. String literals cannot extend over several lines. Examples: 1. `ABCD` 2. `ABCD ` " Length of 4 character " Length of 5 characters50

3. `A``B` & `CD ` " Length of 6 characters Numeric Literals Numeric literals consist of numbers ("0" - "9"). These numbers may be preceded by a plus ("+") or minus sign ("-"). Numeric literals have the ABAP type I or P:

Typ I -2147483648 bis 2147483647 Type P, length 8 If the value can be represented with 15 decimal places, the literal is stored as a P field of the length 8. Type P, length 16 If the value can be represented with 31 decimal places, the literal is stored as a P field of the length 16.

The maximum length for numeric literals is 31 places. Numeric literals with a length of more than 31 decimal places are not allowed and trigger a syntax error.

Use of Data ObjectsUsing Data Objects When you use data objects in ABAP statements, bear in mind that there are two sorts:

51

Non-changeable data objects Changeable data objects

There are also different type requirements for operands. The most important operand types are:

Character-type operands Numeric operands

Changeable Data ObjectsData Objects at Write Positions The following syntax forms are possible for specifying writeable data objects

field field+offset field(length) field+offset(length)

The specification field refers to a data object that is writeable in the current context. Literals, constants, and IMPORTING-VALUE parameters, for example, are not allowed. The specifications offset and length refer to readable data objects with a type and value that can be converted to a number

Non-Changeable Data ObjectsData Objects at Read Positions When specifying readable data objects the following syntax forms are possible:

52

field Simple field specification field+offset Field with offset field(length) Field with length field+offset(length) Field with offset and length 'abc' Character-type literal -nnnn, +nnnn, nnnn Numeric literal

1. 'abc'(xxx)

Text element with default value specification 2. TEXT-xxx Text element

SUM(field) Group total specification for extracts (See LOOP) CNT(field) Group element specification for extracts (See LOOP)

The field specification refers to a simple data object. The specifications offset and length refer to readable data objects with a value that can be converted into a number.

Character-Type Data ObjectsData Objects for Character-Type Operations The data types that can be interpreted as character types are:

53

C Character N Numeric character D Date T Time STRING Character string X Hexadecimal XSTRING Hexadecimal string Flat structures Structures that do not contain any references, internal tables, or strings.

Literals of the 'xxxx' and `yyyy` sort are character-type, as are text elements ( "TEXT-xxx", "'xxxx'(xxx)"). Literals of the nnnn kind (numeric literals) are not character-type. In Unicode progams, stricter constraints apply to character-type operands.

Numeric Data ObjectsData Objects for Numeric Operations The data types that can be interpreted as numbers are:

I Integer P Packed

54

F Floating point X Hexadecimal XSTRING Variable-length hexadecimal strings Character-Type Data Objects, whose content can be converted to a number at runtime.

Numeric literals are always numeric. Character literals and text elements are numeric, if their content can be converted to a number.

Byte-Type Data ObjectsData Objects for Byte-Like Operations The data types that can be interpreted byte-like are:

X Hexadecimal XSTRING Hexadecimal string

Memory RequiredMemory Requirements of Deep Data Types All data types that actually contain work data as the contents of their data objects are referred to as "flat" in ABAP. Therefore, all elementary data types of a fixed length are flat. By contrast, data types that contain references as the contents of their data objects which in turn point to work data in another memory area, are called "deep". Besides data and object references, strings and internal tables also count among the deep data types since they are represented internally also by means of references. Even structures with multiple nesting are only considered deep if they have at least one deep component.

55

Generally, the following is true for data types that are created and managed dynamically:a. Deep data types with a thin fill level, that is, data types with many initial

references, are efficiently managed in ABAP as regards their memory requirements. A reference in initial state requires only 8 bytes of memory.b. Deep data types with a duplicative fill level, that is, data types with many

references that are identical or have the same value, are also efficiently handled in ABAP as regards their memory requirements because objects and data objects are governed by a reference-based semantics. But also with internal tables and strings to which a value-based semantics applies, a sharing logic does not start the copying process until a table involved in the sharing procedure is changed - according to COPY ON WRITE based on reference counting.c. Deep data types with a minimal fill level, that is, data types containing many

references to instances with a small amount of work data, are not handled very efficiently in ABAP as regards their memory requirements. This is the case if the instances are not involved in the sharing procedure since the initial requirements for referenced instances are considerable. This means that you can use deep data types with a thin, duplicative and moderate minimal fill level without restrictions in ABAP. In case of deep data types with a minimal fill level and a low sharing rate, you must consider the initial requirements. Unlike other programming languages, ABAP is not suitable for large-scale use of these data types. As an alternative, you can use a class wrapper since objects have the lowest initial requirements. The following sections indicate the memory requirements of deep data types in their initial state and after the first assignment:

Internal Tables Starting with Release 4.6, table headers no longer exist in the memory area that can be addressed by a user. Only a table reference that uses 8 bytes is retained in this area. From Release 4.6 onwards, empty internal tables therefore only occupy 8 bytes of memory irrespective of whether the table is initial or was reset using FREE.

56

When an internal table contains at least one line or when a previously filled table is reset using only CLEAR and REFRESH, the following memory requirements apply: Release Architecture Requirements 6.10 32-bit 132 bytes 6.10 64-bit 200 bytes 4.6 32-bit 168 bytes 4.6 64-bit 256 bytes

From Release 6.10 onwards, a sharing logic ensures that the table contents are initially not copied during assignments despite their value-based semantics. The copying process is only initiated if a table involved in the sharing procedure is changed. The memory space gained is considerable. Also, the initial memory requirements are limited to 72 bytes for 32-bit architectures and to 96 bytes for 64bit architectures.

Objects Being class instances that are created dynamically, objects are always addressed through a reference. Like an internal table, an initial object therefore uses only 8 bytes of memory. When the object is actually instantiated using CREATE OBJECT, the initial requirements are increased to 36 bytes for 32-bit architectures and to 64 bytes for 64-bit architectures.

Data Objects Being data type instances that are created dynamically, data objects are also addressed through a reference. Like table and object references, they only use 8 bytes of memory if in initial state. When a data object is actually instantiated using CREATE DATA, the initial requirements are increased to 80 bytes for 32-bit architectures and to 100 bytes for 64-bit architectures.

Strings

57

Strings of the type STRING or XSTRING are also addressed through references, using 8 bytes of memory initially. When a string is filled, the initial requirements are increased to 48 bytes for 32-bit architectures and to 72 bytes for 64-bit architectures. As with internal tables, the sharing logic of strings considerably reduces the memory required. The initial requirements for strings involved in the sharing procedure is the same as for initial strings: only 8 bytes.

Display of the Memory Required In order to check the memory required by a program, you can display memory usage hit lists in the ABAP Debugger by choosing Goto System System areas. These lists are available for the following areas: Area Hit list ITABMaximum of 25 internal tables, sorted in ascending order by memory TOP25 required Maximum of 25 objects, sorted in ascending order by memory OBJ-TOP25 required Maximum of 25 data references, sorted in ascending order by memory REF-TOP25 required ALL-TOP25 The 25 program components with the highest memory requirements

You can also choose Settings Memory Display On/Off from the menu to display the required memory referenced and actually used by a specific component.

ReferencesReferences in ABAP

58

A reference is a pointer to an instance, and is contained in a reference variable. A reference variable is a data object, whose type you specify using the REF TO addition in the TYPES or DATA statement. There are various types of reference variables. The type specifies the instances to which the reference can point. The following reference types are currently supported: References --+-- Data references | +-- Object references --+-- Class references +-- Interface references The main distinction is between data and object references.

A data reference can point to any data object. You specify its type using the additions TYPE REF TO DATA or TYPE REF TO type to the TYPES and DATA statements . With the CREATE DATA statement you can use data references to create data objects dynamically. You can write references to existing data objects in to reference variables using the GET REFERENCE statement. In order to access the field that a data reference points to, you use the dereferencing operator ->*. If the data reference is completely typed, that is it has no generic type, you can insert the expression dref->* at any operand position. For all data reference variables you can use ASSIGN dref->* TO assign the field that a data reference indicates to a field symbol . The statements and techniques discussed above are only suitable for working with generic data references. You can also assign a type and, as a result, directly address data references.

Object references can point to objects in ABAP Objects. An object reference can be a class reference or an interface reference:o

Class references allow you to access all of the components of a class. You specify their type using the TYPE REF TO class addition in the TYPES or DATA statement. You can use class references in the CREATE OBJECT statement to create dynamic data objects. Interface references allow you static access to the corresponding interface components of a class. You specify their type using the addition TYPE REF TO ifac in the TYPES or DATA statement. You can also use interface references in the CREATE OBJECT statement with the TYPE addition to create dynamic data objects.59

o

You can check the content of reference variables using the logical expression DS:ABEN.LOGEXP_BOUND> ref IS BOUND. It is true, when a reference variable indicates a valid object.

Typed Data ReferencesTyped Data References - Overview Using Typed Data References As far as fully generic references are concerned, you can edit the data objects created only if you use field symbols. In case of typed data references, however, you can directly address the components of the data object referenced and therefore use them at any operand position required. data DREF type ref to SFLIGHT. create data DREF. DREF->FLDATE = DREF->FLDATE + 5. if DREF->SEATSMAX > 10. write: / DREF->FLDATE, DREF->SEATSMAX. endif. Typing requires that the type of the actual object to which you want to define the reference is known. If this is not the case as, for example, with containers, the only way to access the object is to use the fully generic technique using field symbols. Advantages of Typing A great advantage provided by typed data references is that data ranges are adjusted to the actual requirements. If, for example, you do not know exactly whether a specific field is needed at all in a certain structure, you define a data reference instead of a field and then use CREATE DATA to create the corresponding data object only if the field is addressed. This way, memory requirements at runtime can be reduced considerably. types: begin of STRUC_1, A type I, B type ref to SFLIGHT, C type P, end of STRUC_1. data: S1 type STRUC_1. ... if S1-A > 10. create data S1-B. S1-B->CARRID = 'LH'.60

... S1-B->PAYMENTSUM = 1000. endif. Another advantage as compared with generic data references is that the entire data object can be directly addressed at any operand position using the operator *. The operator * can also be used to create reference chains as shown in the following examples: types: begin of STRUC_2, X(10) type C, Y type ref to STRUC_1, Z type I, end of STRUC_2. data: S2 type STRUC_2, R2 type ref to STRUC_2. ... S2-Y->A = 100. S2-Y->*-A = 200. "Same as S2-Y->A ... S2-Y->B->FLDATE = SY-DATUM. Type Check of Reference Parameters You may only pass a typed reference to a generic parameter typed with reference to REF TO DATA if the parameter is an IMPORTING parameter. In particular, you cannot pass a typed reference to a CHANGING or EXPORTING parameter. This is due to the fact that the reference can be changed in the program unit called with the result that an undefined state exists. In this case, the system triggers a syntax or runtime error. Converting Reference Parameters As with object references, you can always assign a typed reference to a generic reference. In the opposite case, use of the operator ?= is mandatory. data: DREF_1 type ref to data, DREF_2 type ref to SFLIGHT. ... DREF_2 = DREF_1. "Syntax error create data DREF_1 type SFLIGHT. DREF_2 ?= DREF_1. "OK create data DREF_1 type SPFLI. DREF_2 ?= DREF_1. "Exception

61

The exception in the last case can be handled between TRY ... ENDTRY. Internal Tables Like the addition ASSIGNING for internal tables, you can use the addition REFERENCE INTO dref to place a reference to a table line into the field dref. You can then use this reference to directly operate on the contents of the internal table. The addition REFERENCE INTO dref is allowed in the following statements: LOOP, READ, APPEND, INSERT, MODIFY, and COLLECT As a rule, the reference is only set with this addition if the statement is executed successfully. In the LOOP statement, you must not change the reference variable in the loop. When the loop processing is finished, the reference variable points to the table line which was last edited.

TYPES ... TYPE REF TO DATATYPES - For Data References Variant 1 TYPES type.

Addition: ... TYPE REF TO DATA Variables with this type contain references (pointers) to data objects. They can only be dereferenced using an ASSIGN statement. Example TYPES: reftype TYPE REF TO DATA. DATA: numref TYPE reftype, number TYPE I VALUE 123. FIELD-SYMBOLS: TYPE ANY.

62

GET REFERENCE OF number INTO numref. ASSIGN numref->* TO . In this example, a reference is created to the data object number. Subsequently, the data object is assigned to the field symbol using the dereferencing operator ->*. The field symbol can then be processed as usual.

DATA ... TYPE REF TO DATADATA Variant 1DATA f. Addition:

... TYPE REF TO DATA Effect Declares the data object f as a generic data reference variable. Data reference variables of that kind can contain references (pointers) to data objects of any types. They can only be dereferenced using the statement ASSIGN. Example DATA: numref TYPE REF TO DATA, number TYPE I VALUE 123. FIELD-SYMBOLS: TYPE ANY. GET REFERENCE OF number INTO numref. ASSIGN numref->* TO . This example creates a reference to the data object number. It is then assigned to the field symbol using the dereferencing operator ->*. It is now possible to work with the field symbol in the normal way.

Basic StatementsABAP Programming Language

63

This section contains the basic ABAP statements. For further information refer to Basic Statements in the SAP Library.

Data Types and Data ObjectsABAP Data Types and Data Objects Programs work with local data in the program. Data is a sequence of bytes in the memory of the program. Each sequence of bytes that belongs together is called a field, and each field has a length, an identifier (name), and a data type. All programming languages have a concept that explains how the contents of a field (the sequence of bytes) is interpreted according to the particular data types in that language. Within the ABAP type concept, fields are known as data objects. A data object is an instance of an abstract data type. Consequently, data types can occur not only as the attributes of a field, but also as a standalone type definition. Data types and data object have separate namespaces. This means that a data object and a data type can both have the same name, even though they are separate entities. The same visibility rules apply to both data types and data objects: Locally-defined types and objects obscure global types and objects with the same names. The ABAP type concept ensures that the type information belonging to a data object is inseparably joined to it. The syntax check, program generator, and runtime environment always have full type information for every data object. When you create data objcets and specify the types of formal parameters and field symbols, you can refer to a data type (either directly or indirectly):

Using ... TYPE dataType - the data type dataType is addressed directly. Using ... LIKE dataObject - the type of data object dataObject is addressed indirectly.

If dataObject has the type dataType, the indirect reference using ... LIKE dataObject is exactly the same as the direct reference using ... TYPE dataType, that is, ... LIKE dataObject adopts all of the type information of dataObject. At runtime, the inseperable link between data types and data objects means that all type-dependent operations can access full type information, even where programs use untyped parameters and field symbols. For further information, refer to the SAP Library: Data Types and Data Objects

TYPES64

Keywords for data types. Syntax Diagram TYPES Simple type definition - TYPES type. - TYPES type(len). Definition of a structured type - TYPES: BEGIN OF structype ... END OF structype. Definition of an internal table type - TYPES itabtype {TYPE tabkind OF linetype| LIKE tabkind OF lineobj} [WITH [UNIQUE|NON-UNIQUE] keydef] [INITIAL SIZE n]. - TYPES itabtype {TYPE RANGE OF type|TYPES itabtype LIKE RANGE OF f}. - TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n. Additional help Defining Data Types

TYPES - Defining Simple TypesTYPES - Simple Type Definitions Variants: 1. TYPES type. 2. TYPES type(len). The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Implicit type specification notallowed and New naming convention.

65

Variant 1 TYPES type.

Extras: 1. ... TYPE type1 2. ... LIKE f 3. ... TYPE REF TO cif 4. ... TYPE REF TO DATA 5. ... TYPE LINE OF itabtype 6. ... LIKE LINE OF itab 7. ... DECIMALS n 8. ... LENGTH n 9. ... DECIMALS n Effect Creates a new type with the name type. If you do not use the TYPE addition, the new type has the default type C. A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However, these should not be used in application programs. SPACE is a reserved name, and cannot therefore be used. Furthermore, you should not use a field in a statement if it has the same name as one of the additions of the keyword (for example: PERFORM SUB USING CHANGING.). Recommendations for Type Names:

66

1. Always start the name with a letter.2. Use the underscore to separate compound names (for example,

NEW_PRODUCT. Addition 1 ... TYPE type1 Effect The new type is defined by its type type1. type1 may be one of the predefined types listed below, a type that you have defined yourself using TYPES, or a type defined in the ABAPDictionary. The default length ( DL) of the type type depends on the type type1. Type Description DL Initial value

C Character 1 Space N Numeric text 1 '00...0' D Date YYYYMMDD 8 '00000000' T Time HHMMSS 6 '000000' X Byte (heXadecimal) 1 X'00' I Integer 4 0 P Packed number 8 0 F Floating point number 8 '0.0' STRING String variable empty string XSTRING Byte sequence (X string) variable empty X string Example The following TYPES statement defines the type NUMBER as a synonym for the type I (see also ABAP Numeric Types): TYPES NUMBER TYPE I. Addition 2 ... LIKE f The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See LIKE reference to ABAP Dictionary types not allowed.67

Effect The new type is defined by the type of the field f. f may be a field from the ABAP Dictionary or a fiedl in the program that has already been defined. Example TYPES TABLE_INDEX_TYP LIKE SY-TABIX. The type TABLE_INDEX_TYP refers to the type of the field SY-TABIX (system field containing the index of an internal table). Note It is often worth using this addition. If you do so, changes to the type of the field to which you are referring are automatically reflected in your program. It also avoids unnecessary (and possibly unwanted) conversions at runtime. Addition 3 ... TYPE REF TO cif Effect The data type type is declared as a reference in ABAP Objects. cif is either a class or an interface. References are used to type reference variables which, in turn, contain references (pointers) to objects. References that refer to a class are called class references. Likewise, references that refer to an interface are called interface references. Reference variables which are typed using class references can contain object references to objects of that class. Reference variables which are typed using interface references can contain object references to objects whose class implements the interface. Note Objects, that is, instances of classes are only addressed using reference variables. For creating objects, see CREATE OBJECT. Example INTERFACE I1. METHODS M1.68

ENDINTERFACE. CLASS C1 DEFINITION. PUBLIC SECTION. INTERFACES I1. ENDCLASS. TYPES: T_C1 TYPE REF TO C1, T_I1 TYPE REF TO I1. DATA: O1 TYPE T_C1, O2 LIKE O1, IR TYPE T_I1. CREATE OBJECT O1. O2 = O1. IR = O1. CLASS C1 IMPLEMENTATION. METHOD I1~M1. ... ENDMETHOD. ENDCLASS. Additional help Handling Objects Addition 4 ... TYPE REF TO DATA Effect Declares the type type as a reference to a generic data object. Variables with this type contain references (pointers) to data objects. They can only be dereferenced using an ASSIGN statement. Example

69

TYPES: reftype TYPE REF TO DATA. DATA: numref TYPE reftype, number TYPE I VALUE 123. FIELD-SYMBOLS: TYPE ANY. GET REFERENCE OF number INTO numref. ASSIGN numref->* TO . In this example, a reference is created to the data object number. Subsequently, the data object is assigned to the field symbol using the dereferencing operator ->*. The field symbol can then be processed as usual. Addition 5 ... TYPE REF TO type Effect Data type for a typed reference variable. You can use: an elementary type; a type you defined yourself using a TYPES statement; or a type created in the ABAP Dictionary. You can dereference a fully-typed data reference variable in any operand position, using the dereferencing operator, ->*. Example Types: CNTREF type ref to I, FLIGHTREF type ref to SFLIGHT, LINEREF type CNTREF. Addition 6 ... TYPE LINE OF itabtype Effect The specified type itabtype must refer to the type of an internal table (with or without header line). The system creates a type with the line type of the corresponding table type. Example

70

TYPES TAB_TYPE TYPE STANDARD TABLE OF I WITH NONUNIQUE DEFAULT KEY. TYPES MY_TYPE TYPE LINE OF TAB_TYPE. The type MY_TYPE now has the same attributes as a line of the table type TAB_TYPE, that is, type I. Addition 7 ... LIKE LINE OF itab The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See LIKE references to ABAP Dictionary types not allowed. Effect The data object itab must be an internal table (with or without a header line). The system defines a type with the line type of the corresponding table. Example DATA TAB TYPE TABLE OF I. TYPES MY_TYPE LIKE LINE OF TAB. The type MY_TYPE has the same attributes as the line type of the table TAB, that is, type I. Addition 8 ... LENGTH n Effect This addition is only permitted with the types C, N, X, and P. Creates a field of this type with a length of n. Addition 9 ... DECIMALS n Effect

71

You can only use this addition with type P. It assigns n decimal places to the field, which are used both in calculations and for display. n must be between 0 and 14. When you create a new program, the "Fixed point arithmetic" option is set by default. If you switch this option off, the DECIMALS parameter is not observed during calculations, but only when the field is displayed. It is then the responsibility of the programmer to ensure that decimals are properly processed in calcuations by multiplying or dividing by the relevant power of 10 (COMPUTE). You are recommended always to work with fixed point arithmetic. When you do, the system performs all calculations (including intermediate results) to the greatest possible accuracy (31 places). For information about when to use the fixed point type P and the floating point type F, see ABAPNumeric Types. Variant 2 TYPES type(len).

Extras: As in variant 1, except for the LENGTH addition. Effect Creates the type type with the length len. You can only use this variant with the types C, N, P, and X. Types that refer to another type can only be created in their default length (see table under effect of variant 1). The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Wrong length specification in declaration. The permitted lengths depend on the type to which you are referring: Type Permitted length C 1 - 65535 N 1 - 65535 P 1 - 16 X 1 - 65535 Note72

Each byte may contain one character or two decimal or hexadecimal digits. In type P fields, the system reserves one digit for the plus or minus sign, so a P field with length 3 can contain a maximum of 5 digits, while an X field with length 3 can contain 6. In both cases, the displayed length of the field is 6 characters. Additional help Local Data Types in Programs

TYPES - Defining a Structured TypeTYPES - Defining a Structured Type Basic form TYPES: BEGIN OF structype, ... END OF structype. The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Operational statements not allowed in structure definitions and New naming conventions. Effect Defines the structured type structype, where all of the fields defined between " BEGIN OF structype" and "ENDOFstructype" are components of type structype. You can address individual components of the type using the prefix "structype-", A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However