PERFORM is a keyword used in SAP ABAP programming.This tutorial covers its introduction & syntax details.
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.