When you run an exec in the foreground, you do not have use of your terminal until the exec completes. Another way to run an exec is in the background, which allows you to give full control of your terminal while the exec runs. You can run time consuming and low priority execs in the background or execs that do not require terminal interaction. Running an exec in the background is the same as running a CLIST in the background. The program IKJEFT01 sets up a TSO/E environment from which you can invoke execs and CLISTs and issue TSO/E commands. For example, to run an exec named "My exec" containing it in a partition dataset called "User ID dot REXX dot exec" submit the JCL shown here. The exact statement defines the program as IKJVFT01, and the REXX routine and any called routines must be in a PDS defined to the SYSEXEC or SYSPROC system file. You can assign them one or more PDSs to SYSEXEC or SYSPROC. The SYSTSPRT DD allows you to print output to a SYSOUT CLASS or a specified dataset. In the input stream after the SYSTSIN DD, you can issue TSO/E commands and invoke execs and CLISTs. Any additional files needed to run the exec can be defined with the TSO ALLOCATE command within the exec or in the SYSTSIN input stream prior to executing the exec or by adding additional JCL DD statements. It's fairly common to run batch jobs that run REXX execs. If you're only running one exec in your batch job, you may specify it in the PARM parameter on the exec statement. If you wish to run multiple execs, you must specify them in the SYSTSIN DD input stream statement. Note that you have a choice of three program names to run TSO/E in the background, they are IKJEFT01, IKJEFT1A, and IKJEFT1B. The difference is that 1A and 1B provide additional return code and Abend support which may be more suitable to a batch job than 01, which is designed more for interactive use. Running an exec and batch using IRXJCL is similar in many ways to running an exec in the TSO/E background using IKJEFT01. However, there are differences. One major difference is that the exec running in batch via IRXJCL, you cannot use TSO/E services such as TSO/E commands like ALLOCATE and most of the TSO/E external functions. Since exec is running in batch via IRXJCL use TSO/E services, any additional files needed to run the exec must be defined by adding JCL DD statements. The example here shows two job steps, both running the program IKJEFT1A, so they are running TSO/E in batch. In the first step, only one REXX exec is running, MATH3. It's being provided by the PARM parameter on the exec statement. The MATH3 program will prompt us for the two numbers on which to perform arithmetic, and that input is provided via the SYSTSIN DD statement. Notice that when MATH3 requests the next set of numbers, the next line from SYSTSIN will be red. At the next prompt from MATH3, the line containing the word exit is passed to the exec, and will cause MATH3 to terminate. In the second job step, there is no PARM parameter, so IKJEFT1A simply reads from the SYSTSIN. This DD statement can be thought of as almost like the TSO ready prompt. Each line will be read in succession and may include REXX execs to run, input to those execs as responses to PARSE PULL or PASS EXTERNAL, and even TSO/E commands, things like LISTCAT. When the last line from SYSTSIN has been processed, the TSO/E program ends. SYSTSPRT DD will contain all the output that was generated. The example here is running the program IRXJCL, so it is running in an MVS address space with a default host environment command of MVS. Again, there's no PARM parameter, so the program looks to the SYSTSIN DD statement for the work it is to perform. Each line is read again, one at a time, until there's no more work to do. Note the input DD statement in the JCL, which is referenced by the EXECIO command but is executed under the control of REXXTRY. In this example, the DD name input must be provided via the DD statement and not via an ALLOCATE command as that command is not executable in an MVS host command environment. That's basically it for running REXX in batch. Let's shift gears again and start talking about using REXX to execute operator commands.
