How to prevent conflicts with DDNAME SYSEXEC when running Rexx execs in a foreground processor.
Article ID: 11276
Updated On:
Products
Issue/Introduction
How to execute a REXX exec in foreground a processor step that requires a SYSEXEC DD other than the one allocated in the TSO logon procedure?
Resolution
Endevor executes processor steps by performing dynamic allocations for DD statements indicated in the processor step prior to calling
the program and dynamically un-allocating them after the program completes.
When a processor step invokes a REXX EXEC this can cause a conflict in foreground if the processor includes a DD statement for SYSEXEC.
SYSEXEC is the DDNAME used by the REXX environment to find the EXEC's to be executed. If the processor step specifies it, Endevor will not allocate it (as it is already allocated by the TSO session) which might cause trouble to the processor step (for example, not be able to find the REXX).
The easiest way to prevent this conflict is to omit coding SYSEXEC DD in any processor to be executed in foreground, so that the REXX exec being executed will use whatever is allocated to the SYSEXEC DDNAME in the TSO logon procedure.
However, if this is not possible, the REXX environment can be customized so that, only for the scope of the processor step, it uses any ddname other than SYSEXEC for this purpose.
The exact steps are documented in IBM manuals (TSO/E REXX Reference Guide). Briefly, the goal is to build (assemble and link) a REXX defaults parameter module specifying a ddname other than SYSEXEC in the LOADDD parameter, and code that particular ddname in the processor.
The REXX defaults parameter module name depends on the way the EXEC has been initiated:
- IRXPARMS for EXEC's initiated from batch (by the IRXJCL program)
- IRXTSPRM for EXEC's invoked from TSO environment (IKJEFT01)
Feedback
