ABAP Geek 6 – Jam(med) Sessions
ABAP memory organization part2. Internal session internals.
This Blog continues ABAP Geek 5 – In Memory of …. It digs deeper into ABAP’s memory by explaining how an internal session is organized. Maybe one or the other might gain deeper insight from that.
From last ABAP Geek 5 – In Memory of … you know, that each program call (SUBMIT, CALL TRANSACTION, LEAVE TO TRANSACTION) opens an Internal Session in a Main Session. It depends from the program call, if a preceding Internal Session is deleted or stacked to become part of a call sequence. The ABAP Memory is used to pass data between programs of a call sequence.
Main Program Group
Every time an Internal Session is created, its Main Program Group is created. What is a Program Group? A Program Group is an organizational unit of programs in the internal session. There is always a main program group and it is possible to have several additional program groups. Each program group has a main program and can have additional programs. The runtime of the main program in the main program group determines the lifespan of the entire internal mode.
Additional Program Group
This is created when a function group or a class pool is loaded into the internal session. A function group is loaded by means of an external procedure call. A class pool is loaded by usage of its global class (execution of the static constructor). The function group or class pool is the main program of the additional program group. An additional program group, its programs and data are retained for the entire duration of the internal session.
Main Program of a Program Group
The first program of a program group. The first program that is loaded by a program call (SUBMIT, CALL TRANSACTION, LEAVE TO TRANSACTION) into an internal mode is the main program of the main program group. The program (function group or class pool) – for which an additional program group is created when it is loaded – is the main program of the additional program group.
Additional Programs of a Program Group
All programs, that are loaded via an external subroutine call (PERFORM) become additional programs of the caller’s program group. Exceptions of that rule are function groups. Loading a function group always creates a new program group.
Named Data Objects
All global data objects of all programs in an Internal Session are part of the Internal Session. The named data objects of a specific program (declared by DATA etc.) are created, when the program is loaded and are statically visible for their program only. Exceptions are the so called interface work areas (see below). The global data objects of a program live as long as the Internal Session. When you call procedures of a program several times, they always work with the same global data.
Objects (instances of classes) are part of the Internal Session. They are visible to and can be used by all programs and objects of the same internal session. You do so, by passing references between programs and objects. An object lives as long as there are references to the object.
Anonymous Data Objects
Anonymous data objects are created by a CREATE DATA statement and can be addressed using reference variables. They are handled like objects. The only difference is, that objects are instances of object types (classes) and anonymous data objects are instances of data types.
Interface Work Areas
Interface work areas are a dangerous and tricky thing. They are declared with the (partly obsolete) statements TABLES, NODES and the (obsolete) addition COMMON PART of the DATA statement. Interface work areas are created only once per program group and are equally accessed from all programs in a program group.
Important Note: The assignment of a program to a program group depends on the call sequence. Therefore, it depends from user interaction and so on, which interface work areas a program might work with.
Dynpros, Lists, and GUI Status
With CALL SCREEN, you always call the Dynpros of the main program of the current program group. Directly after creating an Internal Session, you call the Dynpros of the main program of the main program group. In additional program groups, only function groups can call their own Dynpros. As a rule, a GUI Status set with SET PF-STATUS is also taken from the program group’s main program. Last but not least, ABAP Lists are always linked to the current Dynpro sequence and therefore also belong to the main program of a program group. As a result, when you work with screens in externally called subroutine, you normally never work with the Dynpros and GUI Status in the subroutines own program, but you execute the dialog modules and list event blocks of the program group’s main program.
Everything that is complex and ambiguous in this blog comes from external subroutine calls.
Without external subroutine calls we would not need the term program group at all!
Don’t use them …