Programs in the Internal Session in sap abap programming language

Programs in the Internal Session

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

Program Groups

• Main Program Group          
• Additional Program Group 
• Main Program of a Program Group 
• Programs Loaded into a Program Group 
• Data Objects 
• Instances of Classes 
• Interface Work Areas

Program Groups

In an internal session, it is possible to load multiple programs that can be organized in program groups. Once an internal session is exited, it is closed. It is then no longer possible to access data and objects of the internal session. 

Main Program Group 

When an internal session is created by calling an ABAP program using SUBMIT or transaction code, the main program group is created and the called program is its main program. The full 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 functional group. 

Programs Loaded into a Program Group 

When programs that do not function groups or class pools are loaded because of an external user, 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 Dynpro statement CALL SUBSCREEN sub_area INCLUDING prog, if the Dynpro 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.

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 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 dynpros, 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. 

Instances of Classes 

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. 

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.

Dynpro, 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 group. The main programs (functional 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 subroutine, for example, never calls a dynpro from its own master program. The dialog modules and list result blocks of the main program are executed.