ABAP Keyword Documentation → ABAP − Reference → Calling and leaving program units → Calling Processing Blocks → Calling Procedures → PERFORM → PERFORM - general
PERFORM - subr_identifier
Other versions: 7.31 | 7.40 | 7.54
Syntax
... subr
| {subr|(sname) IN PROGRAM [prog|(pname)] [IF FOUND]}
| {n OF subr1 subr2 ...} ...
Alternatives
2. ... subr|(sname) IN PROGRAM [prog|(pname)] [IF FOUND] ...
3. ... n OF subr1 subr2 ...
Effect
These names are used in the statement PERFORM
to specify the called program and the ABAP program in which it is defined.
Note
As well as the alternatives shown here, there is another obsolete form of the external subroutine call.
Alternative 1
... subr ...
Effect
When specified directly, subr
calls any subroutine of the current program
using its name declared in the statement FORM
. The subroutine must exist.
Example
Call of a directly specified subroutine without parameters.
PERFORM do_something.
...
FORM do_something.
cl_demo_output=>display( `doing something` ).
ENDFORM.
Alternative 2
... subr|(sname) IN PROGRAM [prog|(pname)][IF FOUND] ...
Effect
If specified, this is used to call any subroutine of the current program or of another program. The subroutine and the program can be specified as follows:
-
subr
subr
.
-
(sname)
sname
. The data object sname
must contain the name of the subroutine in uppercase letters.
-
prog
prog
(static external subroutine call).
-
(pname)
pname
(dynamic external subroutine call). The data object pname
must contain the name of the program in uppercase letters. The following can be specified for pname
:
- Literal or constant
If the data objectpname
is specified as a character literal or as a constant, it can be evaluated statically and the specified program is identified as the used object.
- Variable
If the data objectpname
is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
pname
is not evaluated until runtime (in both cases).
Valid programs for external subroutine calls are executable programs,
module pools,
function groups, and
subroutine pools. If
an external subroutine is specified statically, the syntax check does not check whether the specified program and subroutine exist and also does not check the type of the program. Only the
extended program
check registers any invalid or nonexistent programs or subroutines as errors by default. This also
applies to names specified as constants or literals. If the addition IF FOUND
is specified, the extended program check also skips the check.
If the statically or dynamically specified subroutine or program does not exist at runtime, a handleable
exception of the class CX_SY_DYN_CALL_ILLEGAL_FORM or CX_SY_PROGRAM_NOT_FOUND is raised by default.
If the addition IF FOUND
is specified, the statement PERFORM
is skipped.
If the specified program exists, it is loaded, if required, into the
internal session and
scanned for the specified subroutine. The event LOAD-OF-PROGRAM
is not triggered.
If the subroutine is available, the event LOAD-OF-PROGRAM
is triggered (if not already triggered) and then the subroutine is executed.
Notes
- External calls of subroutines are almost completely obsolete. Instead of subroutines, methods and function modules can be used as explicit functional interfaces of a program.
- Furthermore, external calls of subroutines are critical, since there is usually no static way of determining which program groups are assigned to the master program.
-
If no further addition is specified apart from
IN PROGRAM
(noIF FOUND
, no parameter list), the program name can be omitted and is added implicitly with the name of the current program. -
Any subroutines defined in an
include program cannot be called externally by specifying the include program, since it cannot be generated as a standalone program. The include program can be called, however, by being included in a
compilation unit and by specifying the name of this unit.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
Example
Dynamic call of a subroutine of the same program without parameters.
DATA(subr) = 'DO_SOMETHING'.
DATA(prog) = sy-repid.
PERFORM (subr) IN PROGRAM (prog) IF FOUND.
...
FORM do_something.
cl_demo_output=>display( `doing something` ).
ENDFORM.
Alternative 3
... n OF subr1 subr2 ...
Effect
If specified, this selects a subroutine subr
of the current program from
a list. The list subr1 subr2 ...
can contain up to 256 directly specified
subroutines. n
must be a numeric data object containing a number between
1 and the specified number of subroutines when the statement is executed. The subroutine subr
is called, whose list position is in n
. In this variant, it is not possible
to specify parameter_list
and only subroutines without a parameter interface can be called.
Example
This example calls n
internal subroutines subr_1
through subr_n
successively from a list.
DATA n TYPE i.
...
DO n TIMES.
PERFORM sy-index OF subr_1 subr_2 ... .
ENDDO.
FORM subr_1.
...
ENDFORM.
FORM subr_2.
...
ENDFORM.
...