The @EXEC statement terminates the EDT session and loads and starts the specified program.
Operation | Operands | F mode, L mode |
@EXEC | string | |
string | String specifying the name of the program that is to be loaded and started. |
The @EXEC statement is one of the EDT statements with security implications (see also section “Access protection”). The statement is rejected in uninterruptible system procedures in interactive mode and on input from a file (read with RDATA from SYSDTA not equal to SYSCMD, execution of a start procedure).
The @EXEC statement always causes EDT to be terminated irrespective of whether the specified program file exists or contains a valid program.
As far as the handling of unsaved files and the related security queries is concerned, @EXEC acts in the same way as the @HALT statement (see section “Terminating an EDT session”). Since EDT is always terminated, save queries may, unlike in the case of @HALT, also be issued if the statement was entered in the screen dialog (started with @DIALOG).
If EDT was loaded as a subroutine and the EDT screen dialog has been activated with @DIALOG, the @EXEC statement does not result in the continuation of the subroutine. Instead, the user program is also unloaded.
It is therefore possible to prohibit users from issuing the @EXEC statement when EDT is called as a subroutine. In this case, calls are rejected with message EDT4976.
Note
If @DIALOG was entered in a system procedure, then the remaining procedure commands after @EXEC may be interpreted as input for the newly started program and may therefore result in unexpected effects.
Example
The example assumes that the records present in the work file have not yet been saved.
EDT is to be terminated and LMS is to be loaded and started.
Since the work file has not yet been saved, EDT queries (in the same way as in @HALT),
whether it should really terminate. Only if the user responds Y is EDT terminated and LMS
loaded and started.