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.

Index
© SAP AG 1996