Organization of External Procedure Calls 

Each time you start or call a program with type 1 or M, a new internal session is opened in the current R/3 terminal session. When the program calls external procedures, their main program and working data are also loaded into the memory area of the internal session. Here, there is a difference between calling external subroutines, function modules, and working with classes in ABAP Objects.

Program Groups in an Internal Session

This illustration shows the memory organization for external subroutines and function modules.

The main program (type 1 or M) belongs to a main program group. When you call a function module from a function group that has not already been loaded, an additional program group is created, into which the function group to which the function module belongs is loaded. The additional program group, along with its data, exists for the rest of the lifetime of the internal session.

If you call an external subroutine using PERFORM, the main program of the subroutine is loaded into the existing main program or function group in the corresponding main or additional program group (if it has not already been loaded).

An additional program group is only opened in an external PERFORM if the subroutine belongs to a function group that has not yet been loaded. This will happen if the main program of the subroutine begins with the FUNCTION-POOL statement. The program type does not necessarily have to be set to F.

Classes in ABAP Objects behave like function groups. The first time you address a class (for example, using the CREATE OBJECT statement) or address a static class component, the system opens an additional program group for the class.

Screen Handling

The system only displays and processes the screens, selection screens, and lists of the main program and main program group or function group of an additional program group, along with their associated GUI statuses. The CALL SCREEN and CALL SELECTION-SCREEN statements or list display statements in external subroutines apply to the screens of the main program or function group. The screens are processed in the main program or function group. So, for example, even if the main program of an external subroutine has a screen 100, the CALL SCREEN 100 statement will call the screen number 100 in the calling main program.

Interface Work Areas

Interface work areas that you declare using the TABLES, NODES, or DATA BEGIN OF COMMON PART statements exist once only in each program group, and are shared by all of its programs. Each main program that begins with the PROGRAM or REPORT statement, and each function group that begins with FUNCTION-POOL shares the interface work areas with the main programs of all of its external subroutines.

Dynamic Assignment

The assignment of screens and interface work areas to subroutines is defined by the sequence of the subroutine calls. The first program to call an external subroutine shares its interface work areas with the subroutine, and the subroutine uses its screens. The sequence of the subroutine calls is not necessarily statically defined. Instead, it can change dynamically depending on user actions or the contents of fields. For example, a subroutine may belong to a main program group on occasion when it is run, but the next time, it may belong to an additional program group. For this reason, you should avoid using external subroutines if they use interface work areas or call screens.