13.3    Memory Organization

When you log onto an SAP system, a session opens in the application server and occupies memory. You can open up to sixteen sessions (depending on the restrictions set by your SAP Basis administrator), with each session occupying its own memory space in the application server and linked to its own window in SAP GUI. ABAP programs run within the session (window), and each session is independent of the others.

When you run an executable program or transaction (i.e., programs linked to a transaction code), the system creates an internal session within the main session, as shown in Figure 13.3.

Internal Session

Figure 13.3    Internal Session

Multiple programs can be called within an internal session and are organized into program groups. The first program that is called in the internal session creates a main program group. This program will be the main program of the main program group. When a function module or global class is called from the main program, it creates an additional program group. The main program of the additional group will be the first program that created the additional group.

When a program is called that isn’t a function group or class pool (e.g., external subroutine call), it won’t create an additional program group; instead, it’s loaded into the program group of the user. It’s not the program type that determines the assignment of a program to a program group; it’s the introductory statement. For example, subroutine pool programs use the PROGRAM introductory statement. However, if the introductory statement is changed to FUNCTION-POOL without changing the program type in the program attributes, it will create an additional program group.

When a new program is called using the CALL TRANSACTION or SUMBIT AND RETURN statement, it creates a new internal session. The new internal session creates a new program group, with the called program being the main program of the program group. If a function module or global class is called in this new session, it will create an additional program group.

If a new program is called in the new session using the CALL TRANSACTION or SUMBIT AND RETURN statement, it will again create a new internal session. Every internal session has its own program group. You can have up to nine internal sessions in a main session. If the call sequence exceeds nine internal sessions, it will terminate all internal sessions and lead to a runtime error.

When a function module is called, the system will check if the function group to which the function module belongs already exists in the additional program group. If it exists, it won’t load the function group again; instead, the function module is called directly from the additional program group, which can then access the global data of the function group. If the function group doesn’t exist in the additional program group, then the function group is loaded with all its function modules, and the global data of the function group is initialized.

If the same functional module is called in a new internal session, it creates an additional program group (if not yet created in new session) if the function group doesn’t exist in the additional program group and initializes all its global data. The data accessed by the function module in the new internal session will be different than the data accessed by the function module in the previous internal session.

For example, let’s say two programs A and B call function modules FM1 and FM2, which belong to function group FG1. Program A is executed, which creates an internal session 1 in the main session, creating a main program group. When this program A calls the function module FM1, the function group FG1 is loaded to the internal session 1, creating an additional program group. Let’s then assume FM1 sets some global data in the function group FG1. If program A calls function module FM2 next, the function group FG1 isn’t reloaded, because it already exists in the additional program group, and FM2 can work with the global data set by FM1.

At this point, if program A calls the second program B using a SUBMIT AND RETURN statement, it will create a new internal session 2 with a main program group. The main program of this main program group will be program B. If program B calls the function module FM2, then the function group FG1 is loaded into the internal session 2, creating an additional program group because the function group exists in the additional program group of internal session 1 and not internal session 2. When function group FG1 is loaded in internal session 2, all its global data is reset, so function module FM2 called in program B will be working with the global data of the function group FG1 loaded in session 2. Therefore, the data accessed by FM2 in internal session 1 will be different from the data accessed by FM2 in internal session 2.

All the internal sessions of the main session have access to the ABAP memory of the main session. Programs in the call sequence can exchange data using ABAP memory with IMPORT and EXPORT statements. For example, the calling program can export data to ABAP memory using the EXPORT statement before calling a new program. Once the new program is loaded into the internal session, it can import the data from ABAP memory using the IMPORT statement, as shown in Listing 13.1.

*Code in calling program
DATA v_matnr TYPE matnr VALUE 'ABCD'.
EXPORT v_matnr TO MEMORY ID 'MAT'.
CALL TRANSACTION ZXXX.
*Code in called program
DATA v_matnr TYPE matnr.
IMPORT v_matnr FROM MEMORY ID 'MAT'.

Listing 13.1    Using IMPORT/EXPORT Statements to Access ABAP Memory

ABAP memory can be used to exchange data between programs running in the same main session. Each main session has its own ABAP memory that can’t be accessed from external sessions. To exchange data between programs running in different main sessions of the user session, we use SAP memory.

Figure 13.4 shows the memory organization of ABAP programs.

Memory Organization of ABAP Programs

Figure 13.4    Memory Organization of ABAP Programs

All the main sessions are linked to SAP memory in the user session. Programs running in the internal session can access the SAP memory of the user session. This allows you to exchange data between programs running in different windows of SAP GUI (different main sessions) for the user session. For example, one program running in main session 1 can store data in SAP memory, and another program running in main session 2 can read the data stored by the program running in main session 1. Data can be stored in SAP memory using the SET PARAMETER ID statement and accessed using the GET PARAMETER ID statement. Input fields of the screen can be linked to SAP memory to establish default values.

In Listing 13.2, we created a ZPROGRAM1 program in which we use the SET PARAMETER ID statement to save the value of the v_matnr field in SAP memory and assigning the value "MAT" as the memory ID. Once this value is stored in SAP memory, any program running in the user session can access this value by referring to the memory ID "MAT".

REPORT ZPROGRAM1.
DATA v_matnr TYPE matnr VALUE '100'.
START-OF-SELECTION.
SET PARAMETER ID 'MAT' FIELD v_matnr.

Listing 13.2    Storing Value in SAP Memory

In Listing 13.3, we created program ZPROGRAM2 where we use the GET PARAMETER ID statement to read the value from SAP memory using the same memory ID assigned in Listing 13.2.

Once the GET PARAMETER ID statement is executed, the value stored in the "MAT" memory ID will be transferred to the v_matnr field irrespective of whether the ZPROGRAM2 program is running in the same session as the ZPROGRAM1 program or in a different session.

REPORT ZPROGRAM2.
DATA v_matnr TYPE matnr.
START-OF-SELECTION.
GET PARAMETER ID 'MAT' FIELD v_matnr.

Listing 13.3    Reading Value from SAP Memory

Now that you have an understanding of memory organization, let’s shift our attention to how list screens are processed by programs.