Programs in the Internal Session

The following figure shows the memory organization within an internal session:

Program Groups
In an internal session it is possible to load multiple programs that can be organised in program groups. After
returning from an internal session, this is dismantled. It is then no longer possible to access data and objects of
the internal session.

Main Program Group

During the creation of an internal session using the call of an ABAP program using SUBMIT or a transaction
code, the main program group is created and the called program makes up its main program. The internal
session exists for as long as the main program of the main program group is executed. This can be an
executable program, a module pool, or a function group.

Additional Program Group

Every time that a new class pool or a new function group is loaded by an external usage, an additional program
group is created and the class pool or the function group is the main program of the additional program group.
An external usage is usually an access to components exposed (visible components of the global class or
function module) by the class pool or function group. However, it can also be an access to local components,
such as in a type specification using absolute type names. An additional program group exists for as long as
the internal session exists.

Main Program of a Program Group

The first program loaded of a program group is the main program of this group. The main program of a main
program group is the first program loaded into the internal session due to a program call (executable program,
module pool, or function group). The main program of an additional program group is a class pool or a function
group whose loading results in the forming of the additional program group.

Programs Loaded into a Program Group

When programs that are not function groups or class pools are loaded because of an external usage, they do
not form additional program groups, instead they are loaded into the program group of the user. This happens
for example:

during the external call of subroutines that are defined in executable programs, module pools or
subroutine pools

when using the screen statement CALL SUBSCREEN sub_area INCLUDING prog, if the screen is
not defined in a function group

during dynamic access to a local data type or object type of an executable program, module pool, or a
subroutine using absolute type names

with statements such as SET PF-STATUS OF PROGRAM, if the program of the necessary component
is not a function group.

Notes

It is not the program type that is important for the assignment of a program to a program group, but the
introductory program statement. For example, if the the statement FUNCTION-POOL is used in a
subroutine pool instead of PROGRAM, when the program is loaded by an external usage it forms an
additional program group.

Since all the programs of a program group use the interface work area, the screens, lists, and GUI
statuses of the main program (more below), the assignment of a program that is loaded into a program
group is particularly important if procedures of this program are called externally.

Data Objects

The data objects of a program, with the exception of the interface work area, belong exclusively to their
program and are only visible there. A loaded program exists for the same length of time as the internal session.
After returning from a program, its data objects are retained and are available if a procedure of the program is
called again.

Class Instances
Objects as instances of classes can be used by all programs (and objects) of an internal session. An object
exists for as long as there are users for (and hence references to) the object.
Note
This means that references to objects of the internal session can be transferred to externally called procedures.

Interface Work Areas

Data objects declared with TABLES or DATA BEGIN|END OF COMMON PART ... are interface work areas.
These are only created once per program group and are used by all programs of a program group together.
Note
The assignment of a program to a program group, and thus the determination of which other programs it
shares the interface work area with, can depend on the usage sequence.

Dynpros, Lists, and GUI Statuses

Only the dynpros of the main program of a program group can be called using CALL SCREEN. After an internal
session is loaded, these are the dynpros of the main program of the main program group. The main programs
(function groups) of additional program groups can also call their own dynpros.
Lists are always assigned to the current dynpro sequence and therefore also to the main program of the
program group.
As standard, SET PF-STATUS is used to access the GUI status of the main program of a program group and
use its data objects for dynamic texts.
All programs of a program group work with the dynpros, lists, and GUI status of the main program by default. A
statement CALL SCREEN in an externally called subprogram, for example, never calls a dynpro from its own
framework program. The dialog modules and list result blocks of the main program are executed.