ABAP Geek 6 Jam(med) Sessions
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.
Internal Session
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
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.
Bottom line
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 …
For example, often I'll want to code something like below, but it requires me to add table T001 with the TABLES statement.
SELECT-OPTIONS:
s_bukrs FOR t001-bukrs.
Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.
I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I'm sure it could be worked around. For example, perhaps the variable coupling requirement could be dropped for select-options defined using:
SELECT-OPTIONS:
s_bukrs TYPE RANGE OF t001-bukrs.
And while I'm on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased? Makes for less-readable code.
Gripe over (I really do like the language 🙂
Regards,
Scott
Tell me about it!
😉
For example, often I'll want to code something like below, but it requires me to add table T001 with the TABLES statement.
SELECT-OPTIONS:
s_bukrs FOR t001-bukrs.
Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.
I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I'm sure it could be worked around. For example, perhaps the variable coupling requirement could be dropped for select-options defined using:
SELECT-OPTIONS:
s_bukrs TYPE RANGE OF t001-bukrs.
And while I'm on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased? Makes for less-readable code.
Gripe over (I really do like the language 🙂
Regards,
Scott
Tell me about it!
😉
For example, often I'll want to code something like below, but it requires me to add table T001 with the TABLES statement.
SELECT-OPTIONS:
s_bukrs FOR t001-bukrs.
Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.
I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I'm sure it could be worked around. For example, perhaps the variable coupling requirement could be dropped for select-options defined using:
SELECT-OPTIONS:
s_bukrs TYPE RANGE OF t001-bukrs.
And while I'm on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased? Makes for less-readable code.
Gripe over (I really do like the language 🙂
Regards,
Scott
Tell me about it!
😉
And if so - it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
Christian
the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.
In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.
Horst
that was pretty much that I expected...
Christian
And if so - it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
Christian
the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.
In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.
Horst
that was pretty much that I expected...
Christian
And if so - it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
Christian
the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.
In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.
Horst
that was pretty much that I expected...
Christian