The following diagram shows the memory organization within an internal session:
Several programs can be loaded in an internal session, which are organized 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.
For transferring data between the programs of a call sequence, the ABAP memory can be used.
When an internal session is opened by a program call, the main program group is created.
If a function group is loaded in an internal session using an external procedure call, or through the use of its global class, a class pool is loaded, then an additional program group is created.
The program that is loaded first from a program group is the main program of this group.
All programs apart from function groups, which are loaded by the external call of a subprogram, are assigned to the program group of the calling program.
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.
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.
This means that references to objects of the internal session can be transferred to externally called procedures.
Data objects declared with TABLES, NODES, 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.
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 call sequence.
The table work area dbtab declared in the program sapssubr is shared with either sapmprog or saplfugr. If share has the value 'FUGR', saplfugr and sapssubr use the table work area together. Otherwise, it is shared between sapmprog and sapssubr.
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.