Ansicht
Dokumentation

ABENPROGRAM_GROUPS - PROGRAM GROUPS

ABENPROGRAM_GROUPS - PROGRAM GROUPS

ROGBILLS - Synchronize billing plans   General Material Data  
This documentation is copyright by SAP AG.
SAP E-Book

Program Groups in External Procedure Calls

The programs within an internal session form program groups there. There is always one main program group and possibly multiple additional program groups. Each program group contains a main program and any other programs loaded. If, during an external procedure call, the procedure accesses shared resources of the program group, it is important to know the program group of the compilation unit of the procedure. This determines whether non-critical external procedure calls and critical external procedure calls are made.

Non-Critical External Procedure Calls

The only procedures intended for external calls are the visible methods of global classes and function modules. The compilation units of these procedures are always main programs of their program groups and it is always determined that the procedures work with the resources of this program group.

Note

For this reason, only the methods of global classes and function modules should be called externally.

Critical External Procedure Calls

Subroutines and the methods of local classes are not intended for external calls. Both in external subroutine calls and in dynamic calls of the local class of a program that is not its own program group, there is no static assignment to a program group. The program in which a program that is yet to be loaded is used for the first time determines the program group. The order of the user actions, field content, or switches can determine the order of usage, which means that the compilation unit of the procedure can belong to the main program group in one instance, and to an additional program group in another instance.

The way external procedures of additionally loaded programs are used is critical for the following reasons:

  • Within a program group, only the dynpros, selection screens, lists, and GUI statuses of the main program are used. For example, the statement CALL SCREEN does not call any dynpros of its own compilation unit in an externally called subroutine of another loaded program and calls a dynpro of the main program of its program group instead. The responses to user actions are also raised in the main program.

This means there is no static way of determining which interface work areas and which screens are used by an externally called subroutine or local class. The following figure shows how programs are loaded into program groups, using the example of an external subroutine call.

IMAGE @@ABDOC_Prog_Group.gif@@623@@538@@

Subroutines and methods of local classes must always be called internally and never externally.

Note

The text elements of an additionally loaded program are always taken from its own text pool.

Example

The table work area dbtab declared in sapssubr is shared either with sapmprog or with saplfugr. If share has the value 'FUGR', saplfugr and sapssubr share the table work area. Otherwise, it is shared by sapmprog and sapssubr.

PROGRAM sapmprog.
TABLES dbtab.
...
IF share = 'FUGR'.
  CALL FUNCTION 'FUNC'.
ENDIF.
...
PERFORM sub IN PROGRAM sapssubr.

FUNCTION-POOL saplfugr.
TABLES dbtab.
...
FUNCTION func.
  PERFORM sub IN PROGRAM sapssubr.
ENDFUNCTION.

PROGRAM sapssubr.
TABLES dbtab.
...
FORM sub.
  ...
ENDFORM.






General Material Data   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 5566 Date: 20240328 Time: 180901     sap01-206 ( 100 ms )