Use the IMFEXEC SELECT statement in an EXEC to allow one EXEC to schedule another EXEC-initiated EXEC, which are usually subroutines (or service routines) that carry out specialized tasks needed by several automation procedures.

An EXEC can schedule another EXEC under the same thread (synchronously) or under a new thread (asynchronously). If IMFEXEC SELECT is coded with WAIT(YES), the called EXEC is scheduled to execute under the same thread. Otherwise, the called EXEC executes as a separate task under a new thread.

Passing control of an EXEC

By specifying the WAIT(YES) parameter on an IMFEXEC SELECT statement, an EXEC can schedule another EXEC, wait for its completion, and then resume execution.

When an EXEC schedules another EXEC by using the WAIT(YES) parameter, control is passed immediately to the called EXEC. The called EXEC can use the IMFEXEC statements VDCL, VGET, and VPUT to access all the LOCAL, GLOBAL, and SHARED variables created by the first EXEC, but it does not have access to any of the TSO variables created by the first EXEC.

The execution of the calling EXEC is suspended when the called EXEC is being processed. When the called EXEC terminates, the first EXEC receives control at the first statement immediately after the IMFEXEC SELECT statement.

BBI variables IMFCC and IMFRC are used to report the success of the scheduled WAIT(YES) EXEC. See Understanding-completion-codes-for-EXEC-Initiated-EXECs-with-WAIT-YES-and-User-Written-programs for a complete discussion.

For EXECs scheduled with the IMFEXEC SELECT EXEC( ) WAIT(yes) statement, the two ways to pass back results are using

• IMFEXEC EXIT CODE(x)
• a local, shared, or profile variable

Using RETURN will give control back to the calling EXEC but the passed back value (RESULT) is not supported.

The following table shows where you can find more information: