PERFORM

Variants
1. PERFORM form.
2. PERFORM form(prog).
3. PERFORM form IN PROGRAM prog.
4. PERFORM n OF form1 form2 form3 ... .
5. PERFORM n ON COMMIT.
Variant 1
PERFORM form.
Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...
3. ... TABLES itab1 itab2 ...
Effect
Calls the subroutine form specified in the FORM statement. On completion, processing in
the main program resumes.
Example
PERFORM HELP_ME.
...
FORM HELP_ME.
...
ENDFORM.
The PERFORM statement calls the subroutine HELP_ME .
Notes
Nested calls are allowed (i.e. PERFORM within a FORM ... ENDFORM ).
Recursive calls are also possible.
To define local data, use the DATA statement after FORM . Each time you enter the
subroutine, the data is recreated (with an initial value) and released at the end (from the
stack).
To define global data used within a subroutine, use the LOCAL statement after FORM .
The values are saved when you enter the subroutine and then released at the end (from

the stack).
Note
Runtime errors
PERFORMANCE_PARAMETER_MISSING : The called form expects more parameters
than were specified.
PERFORM_PARAMETER_COUNT ,
PERFORM_TOO_MANY_PARAMETERS : More parameters were given than
the FORM expected.
PERFORM_CONFLICT_TYPE ,
PERFORM_CONFLICT_GENERIC_TYPE ,
PERFORM_BASE_WRONG_ALIGNMENT ,
PERFORM_PARAMETER_TOO_SHORT ,
PERFORM_TABLE_REQUIRED : The parameter type does not match the type
specified in the FORM definition.
PERFORM_BASE_LITL : A literal was passed to a structured parameter.
Addition 1
... USING p1 p2 p3 ...
Addition 2
... CHANGING p1 p2 p3 ...
Effect
These additions are equivalent to each other. For documentation reasons however, you
should use the same one as with the associated FORM definition.
Both additions pass the parameters p1 p2 p3 ... to the called subroutine. You can use as
many parameters as you like.
Sequence is important here because the first parameter of the PERFORM call is passed to
the first parameter of the FORM definition, the second to the second and so on.
You can use the following as parameters:
DATA fields (see DATA )
Field strings (see DATA BEGIN OF )
Literals
Field symbols (see FIELD-SYMBOLS )
Parameter offset and length can be passed as variables. The addition ' ...USING p1+off(*)
' causes parameter p1 to be passed with offset off so that the field limits of p1 are not
exceeded.
Example
DATA: NUMBER_I TYPE I VALUE 5,
NUMBER_P TYPE P VALUE 4,

BEGIN OF PERSON,
NAME(10) VALUE 'Paul',
AGE TYPE I VALUE 28,
END OF PERSON,
ALPHA(10) VALUE 'abcdefghij'.
FIELD-SYMBOLS .
ASSIGN NUMBER_P TO .
PERFORM CHANGE USING 1
NUMBER_I
NUMBER_P
PERSON
ALPHA+NUMBER_I().
FORM CHANGE USING VALUE(PAR_1)
PAR_NUMBER_I
PAR_NUMBER_P
PAR_POINTER
PAR_PERSON STRUCTURE PERSON
PAR_PART_OF_ALPHA.
ADD PAR_1 TO PAR_NUMBER_I.
PAR_NUMBER_P = 0.
PAR_PERSON-NAME+4(1) = ALPHA.
PAR_PERSON-AGE = NUMBER_P + 25.
ADD NUMBER_I TO PAR_POINTER.
PAR_PART_OF_ALPHA = SPACE.
ENDFORM.
Field contents after the PERFORM call are as follows:
NUMBER_I = 6
NUMBER_P = 6
=6
PERSON-NAME = 'Paula'
PERSON-AGE = 25
ALPHA = 'abcde j'
Note
The field type and length of the parameters remain. If parameter values change within the
subroutine, these new values remain after you leave the subroutine. However, this does
not apply to parameters passed with VALUE (see FORM ).
If you pass literals, you must either leave them unchanged or pass them in the FORM
definition with the USING VALUE statement.
Addition 3

... TABLES itab1 itab2 ...

Effect
You use TABLES to pass internal tables to subroutines.
Example
DATA: BEGIN OF ITAB OCCURS 100,
TEXT(50),
NUMBER TYPE I,
END OF ITAB.
STRUC LIKE T005T.
...
PERFORM DISPLAY TABLES ITAB
USING STRUC.
FORM DISPLAY TABLES PAR_ITAB STRUCTURE ITAB
USING PAR STRUCTURE T005T.
DATA LOC_COMPARE LIKE PAR_ITAB-TEXT.
WRITE: / PAR-LAND1, PAR-LANDX.
...
LOOP AT PAR_ITAB WHERE TEXT = LOC_COMPARE.
...
ENDLOOP.
...
ENDFORM.
Within the subroutine DISPLAY , you can apply all the available table operations to the
internal tables passed.
Note
TABLES must always appear first in the PERFORM call. It must not be preceded by an
addition.
Variant 2
PERFORM form(prog).
Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...
3. ... TABLES itab1 itab2 ...

4. ... IF FOUND
Effect
Calls the subroutine form defined in the program prog (i.e. external PERFORM ).
Notes
Parameter passing to the external subroutine is the same as in variation 1.
Parameter passing can be implemented by using a common data area (see DATA BEGIN
OF COMMON PART ).
Nested calls are possible, even with several external subroutines from different programs.
If you call a subroutine of a program prog , the system loads the program prog
Note
Runtime errors
PERFORM_NOT_FOUND : The subroutine specified was not found.
Addition 1
... USING p1 p2 p3 ...
Effect
See addition 1 of variation 1.
Addition 2
... CHANGING p1 p2 p3 ...
Effect
See addition 2 of variation 1.
Addition 3
... TABLES itab1 itab2 ...
Effect
See addition 3 of variation 1.
Addition 4
... IF FOUND
Effect
Calls the specified subroutine only if it already exists. Otherwise, the statement is
ignored.
Notes
If the program specified is not available or incorrect, a runtime error is output.
The only way of determining whether the specified routine existed (in an available
program) is by writing your own program (e.g. by setting a flag that is passed to the

subroutine).
Variant 3
PERFORM form IN PROGRAM prog.
Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...
3. ... TABLES itab1 itab2 ...
4. ... IF FOUND
Effect
Similar to variation 2 (external PERFORM ), except that here you can specify both the
subroutine and the program dynamically (at runtime); in this case, you must enclose the
variables form or prog in parentheses. If you omit specification of the program after IN
PROGRAM , ABAP/4 searches for the routine in the current program.
Example
DATA: RNAME(30) VALUE 'WRITE_STATISTIC',
PNAME(8) VALUE 'ZYX_STAT'.
PERFORM WRITE_STATISTIC(ZYX_STAT).
PERFORM (RNAME) IN PROGRAM ZYX_STAT.
PERFORM WRITE_STATISTIC IN PROGRAM (PNAME).
PERFORM (RNAME) IN PROGRAM (PNAME).
All four of the above PERFORM statements have the same effect, i.e. they call the
subroutine 'WRITE_STATISTIC' defined in the program 'ZYX_STAT' .
Note
This dynamic PERFORM requires more CPU time, since the system has to search for the
subroutine each time.
Addition 1
... USING p1 p2 p3 ...
Effect
See addition 1 of variation 1.
Addition 2
... CHANGING p1 p2 p3 ...

Effect
See addition 2 of variation 1.
Addition 3
... TABLES itab1 itab2 ...
Effect
See addition 3 of variation 1.
Addition 4
... IF FOUND
Effect
Calls the specified subroutine only if it already exists. Otherwise, the statement is
ignored.
Variant 4
PERFORM n OF form1 form2 form3 ... .
Effect
Drives a subroutine specified by the index n from a list of subroutine names listed in the
statement. At runtime, the variable n must contain a value between 1 (first name) and the
total number of subroutines specified (last name). Up to 256 subroutine names are
possible.
Note
Runtime errors
PERFORM_INDEX_0 : The index specified was too small.
PERFORM_INDEX_NEGATIVE : The index specified was negative.
PERFORM_INDEX_TOO_LARGE : The index specified was too large.
Variant 5
PERFORM n ON COMMIT
Addition

1. ... LEVEL level

Effect
Executes the specified subroutine when a COMMIT WORK occurs. This allows you to
execute a subroutine only if the logical transaction has ended successfully. The

subroutine is not executed until the key word COMMIT WORK is called. FORMs
specified several times are executed only once on COMMIT WORK (see COMMIT
WORK ).
If you call ROLLBACK WORK , you delete all the specified routines.
Note
With PERFORM ... ON COMMIT , you cannot transfer any data with
USING/CHANGING . To do this, you must either store the data in global variables or
store it temporarily with EXPORT ... TO MEMORY .
Addition 1
... LEVEL level
Effect
The addition LEVEL , followed by a field, defines the order in which the subroutines are
executed after COMMIT WORK . They are called in ascending order of level. If there is
no addition LEVEL , the subroutine always has the level zero. If the level is the same, the
order of calls determines the order of execution. Level assignment occurs during
development, e.g. by defining constants in an include program. The level must be of type
I.