1. WAIT UP TO time SECONDS.
2. WAIT UNTIL logexp.
WAIT UP TO time SECONDS
The program execution is interrupted for time seconds. After this period, the program processing resumes.
The system interprets the field time as an integer. This allows you to enter waiting periods in seconds.
WAIT UNTIL logexp.
Before executing the WAIT statement, the condition in
the logical expression logexp
is evaluated. If this is satisfied, the execution of the program continues after
WAIT. Otherwise, the results of the previously called asynchronous
Remote Function Call are accepted until one of the FORM
routines (RECEIVE RESULTS FROM FUNCTION func) that performs the task in
question satisfies this condition or until there are no more asynchronous calls. In both cases, the program processing continues after WAIT.
WAIT should only be used with asynchronous
Remote Function Calls (CALL FUNCTION func ...STARTING NEW TASK
task name) and the addition PERFORMING form ON END OF TASK. It has no effect in other environments.
When using WAIT with asynchronous function module calls,
you are recommended to set a variable in the FORM routine
(RECEIVE RESULTS FROM FUNCTION func) that performs the task in question.
This variable is then used in the logical expression specified with WAIT.
... UP TO time SECONDS.
This addition defines the maximum execution time of the WAIT
statement. If the condition of the
logical expression logexp is not satisfied, this statement
should be executed within no more than time seconds. The
program processing then continues after WAIT if either
the condition of the logical expression was satisfied by the subroutine
that performs the task in question, or the specified time period time
has been exceeded. Internally, the system interprets the field time
as a floating point number. The internal resolution of the time period is performed in millisecond units.
This means that the smallest possible time period is 1 millisecond (i.e.
WAIT UNTIL logexp. UP TO '0.001' SECONDS).
The Return Code is set as follows:
Replies to asynchronous calls can only be received if there is a change of roll area (e.g. a screen change) or if you use WAIT (online and in the background).
Since the ABAP debugger has its own internal flow logic (just like related roll area changes), this
can have a considerable effect on the execution of the WAIT statement in debugging mode.
If the key word SET USER-COMMAND is used in the subroutine that
evaluates the results of an asynchronous call (see
RECEIVE), WAIT can postpone the processing of SET USER-COMMAND, but only if it has already been executed.
If the calling program that contains asynchronous calls terminates when it is expecting replies, the incoming replies cannot be processed.
Note that a database COMMIT may occur in certain circumstances after a WAIT
statement. For this reason, do not use WAIT between two Open SQL statements that open and close a database cursor (such as SELECT...ENDSELECT).
DATA: INFO LIKE RFCSI,
* Result of RFC_SYSTEM_INFO function
SEMAPHORE(1)
VALUE SPACE, "For WAIT condition
MSG(80) VALUE
SPACE. "Handling of exceptions
RET_SUBRC
LIKE SY-SUBRC. "Handling of SUBRC
CALL FUNCTION 'RFC_SYSTEM_INFO'
STARTING NEW TASK 'INFO'
DESTINATION 'NONE'
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE =
2 MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: 'Wait for reply'.
WAIT
UNTIL SEMAPHORE = 'X'.
IF RET_SUBRC <> 0.
WRITE MSG.
ELSE.
WRITE: / 'Destination =', INFO-RFCDEST.
ENDIF.
ELSE.
WRITE MSG.
ENDIF.
...
FORM RETURN_INFO USING TASKNAME.
RECEIVE
RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT
= INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE =
2 MESSAGE MSG.
RET_SUBRC = SY-SUBRC. "Set RET_SUBRC
SEMAPHORE = 'X'. "Reset semaphore
ENDFORM.
Non-Catchable Exceptions