Monday, March 17, 2014 12:32 PM

When a developed object is generated, a Runtime Object or LOAD is generated. LOAD largely consists of byte code linked with C functions. Program LOADs can be saved on Database and buffered on Application Server. The LOAD is generated automatically when the program is called if none exists yet or if the LOAD in the database or the program buffer is obsolete. To generate a LOAD select Program->Generate.

You can start the SAP load generator (TCode SGEN) after the import. If you change a development object and then save it, the system creates an active version and an inactive version. The syntax check is carried out on the version in development, not the generated version. This means it can be performed on the inactive version. When running the source code for executable programs that are started from the Editor, the system goes back to the inactive version. In this case, a temporary generated version is created, but is not buffered or stored in the database. In all other cases, the system always accesses the active version when the program is generated.
All inactive objects that are assigned to your user ID are listed in your worklist. The following steps occur when you activate an object (or several objects):

1. The object is saved that is, a new inactive version is created. 2. This is subject to a syntax check. 3. The system then overwrites the current active version. The previously inactive version is now the active version. There is no longer an inactive version. 4. The system creates a new runtime version. The LOAD is updated.

When the runtime system generates a new runtime object (the LOAD) of a program or loads it from the database, the program is placed in the working memory of the application server. In the process, the modifiable parts of the program are treated differently than the non-modifiable parts. The non-modifiable parts of a program are: 1. Byte code for statements 2. Values of constants and literals 3. Program texts 4. Screen definitions
The modifiable parts of a program are: 1. Data objects (variables) The non-modifiable parts of the program are stored in the program execution area (PXA) and buffered there as long as possible. This memory area is shared by all users on the application server and only exists once on each server. After a program is executed, its byte code remains buffered in the PXA as long as possible, to avoid having to load it from the database again during the next execution. The modifiable parts of the program are created from scratch in the memory during every execution (in a memory space called the roll area). If a program is executed several times concurrently (by the same user or different users), each execution has its own roll area. This ensures that the programs can be executed independently of one another.
Advanced ABAP Page 1

memory during every execution (in a memory space called the roll area). If a program is executed several times concurrently (by the same user or different users), each execution has its own roll area. This ensures that the programs can be executed independently of one another. External session (main session) Generally, an external session corresponds to an SAPGUI window. You can create a new session with SystemNew Session or by calling /O tcode. Up to 16 external sessions are possible in Release 7.0 and later (the maximum was 6 in earlier releases). The maximum number available in a given system is defined by system parameter rdisp/max_alt_modes, whose default value is 6.

Internal session External sessions are subdivided into internal sessions (placed in a stack). Each call of an ABAP program (SUBMIT, CALL TRANSACTION, and so on) generates a new internal session. A maximum of nine internal sessions can exist in each external session; they must all belong to the same call stack. One roll area is reserved for each internal session.
When a program calls external modularization units, the corresponding programs are loaded into the same internal session. The programs within an internal session form program groups. When an internal session is opened with a program call, the main program group is always created. There can also be one or more additional program groups. Each program group contains one main program and possibly other programs as well. A program's data objects are only visible within its program group, which means programs in different program groups do not share any data objects.

Memory Management for program Calls 1. Insert a Program

2. Start a new executable program

Advanced ABAP Page 2

3. Start a new transaction

Each function group and each global class is loaded to a given internal session exactly once. If two programs run in the same internal session (for example, an executable program and the AB function group it addresses) and both programs address the same XY function group, then function group XY is only loaded into the internal session once. Therefore, the main program and function group AB can exchange data via function group XY. The same applies for global classes.
When a subroutine is called externally, no new program group is generated in the internal session. Instead, the main program of this subroutine is also loaded into the calling program's existing program group. (Subroutines of a function group are an exception to this: When this type of subroutine is called externally, the corresponding function group is loaded into an additional program group)

SAP memory is a user-specific memory area for storing field values. It is therefore not very useful for passing data between internal sessions. Values in SAP memory are retained for the duration of the user's terminal session. SAP memory can be used between sessions in the same terminal session. All external sessions of a user session can access SAP memory. You can use the contents of SAP memory as default values for screen fields.
ABAP memory is also user-specific. There is a local ABAP memory for each external session. You can use it to exchange any ABAP data objects (fields, structures, internal tables, complex objects) between the internal sessions in any one external session. When the user exits an external session (/i in the command field), the corresponding ABAP memory is automatically initialized or released.

When you call programs using transaction codes, you can only use the ABAP memory to pass data to the transaction in the insert case (CALL TRANSACTION).

Strings and internal tables are dynamic data objects whose memory requirements can change during the program runtime. They are called deep data objects, whose working data is managed internally, using references. Other deep data objects include references and structures that contain at least one deep component, regardless of their nesting.

Advanced ABAP Page 3

Memory Management for Strings

When a program is loaded, only a reference is created for the statically declared deep data objects at first, such as strings and internal tables. The static memory requirement for this reference is eight bytes. When the deep data object is used, additional working memory is requested at the program runtime. For dynamic data objects (strings and internal tables), this memory is for the administration information (header) and the data object itself. The memory requirement for a header depends on the hardware platform, but is generally around 100 bytes. If the requested (allocated) memory is not sufficient during a later access, additional memory can be reserved.
When a string is initialized with CLEAR or FREE, the data itself is deleted, but the reference variables and the header remain. They are used again during the next memory request. Accordingly, when a string has been used and then deleted, its memory requirement consists of the reference and the requirement of the header.

Memory management of Internal Tables

Headers of internal tables normally require less space than other headers, because their data can be distributed among several blocks, which means the header may have to manage references to these blocks.

The CLEAR, REFRESH, and FREE statements have different effects: CLEAR and REFRESH only delete the data itself, while FREE can also delete the table header if it takes up too much memory. You can specify a number of rows, n, as numeric literals or numeric constants in the INITIAL SIZE addition. The system then selects the size of the first block in memory to fit this exact number of lines.
If the specified initial memory requirement is vastly exceeded when the internal table is filled, this might cause the system to allocate much more memory than is needed. Therefore, we only recommend specifying the initial memory requirement if you know the number of entries in the table beforehand and you want to size the initial main memory requirement as specifically as possible. Memory Optimization when Copying Dynamic Data Objects

This approach is called copy-on-write semantics.

Integers (Fixed Point Arithmetic) Whole numbers with type i are represented internally as binary numbers with a length of 4 bytes. They therefore have a value range of -2^31+1 to 2^ 31-1. Calculations with integer arithmetic are faster than calculations with fixed point or floating point arithmetic, because they are executed directly using the processor's arithmetic command set. In contrast to many other programming languages, integer arithmetic in ABAP rounds to the next whole number.
Float (Floating Point Arithmetic)

Advanced ABAP Page 4

The floating point operations of the relevant processors are used for calculations in floating point arithmetic. Since algori thms are converted to binary, inaccuracies can occur. The extent and effect of these inaccuracies are difficult to estimate. Due to these effects, floating point arithmetic is unsuitable for business calculations, because these calculations usually have to be exact "to the penny" and comply with lega l rounding regulations. You should, therefore, use floating-point numbers for approximations only. When you compare floating point numbers, always use intervals, and always round at the end of your calculations. The main advantage of floating point numbers is their large range of values, from 2.2250738585072014E -308 to 1.7976931348623157E+308, including both positive and negative numbers and zero. In addition, you must use floating point numbers for special aggregati on functions of the SELECT statement.

Advanced ABAP Page 5