Running Workload Automation Programming Language within an online TSO session

Workload Automation Programming Language is primarily designed for use in batch, but you can use it from within an online TSO session, either inside or outside of the HCL Workload Automation for Z dialogs.

To use Workload Automation Programming Language from within a TSO session, allocate the following files.

Note: Ensure that the appropriate level of the HCL Workload Automation for Z load library is in the execution path, either through the link list or a STEPLIB statement.

EQQMLIB: The HCL Workload Automation for Z message library. If Workload Automation Programming Language is being run from within HCL Workload Automation for Z dialogs, this file is already allocated.
EQQMLOG: The HCL Workload Automation for Z message log.
EQQOPTS: Optional file to provide environment default options. Allocate this file only if you want to set environment defaults before any commands that the process will run. For online performance reasons, to prevent additional dynamic allocations, it is more efficient to include any relevant statements in the main command stream.

To allocate the files, you can use one of the following ways:

Within the TSO logon procedure.
Within a startup CLIST or REXX, called as part of the TSO logon process.
Within an application CLIST or REXX that starts the set of dialogs in which Workload Automation Programming Language is being called, using ALTLIB and LIBDEF for REXX and ISPF libraries. This process can also free the files as the set of dialogs is exited.
In each individual REXX process that calls Workload Automation Programming Language, using ALTLIB and LIBDEF for REXX and ISPF libraries. This process can also free the files as the set of dialogs is exited.

Note: If you use mechanisms that free the files on exit, ensure that you do not design a process that would cause problems for other applications running in ISPF, in particular where split screen is needed.

Workload Automation Programming Language can then be called as an external EXEC from within calling REXX, with the following syntax:

CALL EQQYXTOP (<subsys> <options>)
waplRC = RESULT

When run within TSO, the INPUT stream is read from a file called INPUT. Workload Automation Programming Language does not read from a file called SYSIN to prevent the risk of stalling if SYSIN was left allocated to the terminal, which is the default position of SYSIN in the foreground. Alternatively, input can be placed on the REXX stack before calling Workload Automation Programming Language by passing an option of INPUT(-OFF-); commands are read directly from the stack without having to allocate an input file to pass the commands.

The EQQJOBS process creates some examples in the EQQJOBS output file that you can use, and optionally customize, as a basis to run Workload Automation Programming Language online:

EQQWTSO1: Shows how to define a Workload Automation Programming Language environment, run a complete Workload Automation Programming Language process, and reset the environment in a single member.
EQQWTSO2: Shows how to run a complete Workload Automation Programming Language process in a single member, having the environment already set up.
EQQWTSO3: Shows a generic Workload Automation Programming Language execution member that defines a Workload Automation Programming Language environment, calls Workload Automation Programming Language with commands queued before this member is called, and then resets the environment without processing any output.
EQQWTSO4: Shows a generic Workload Automation Programming Language execution member that assumes that a Workload Automation Programming Language environment has already been defined, calls Workload Automation Programming Language with commands queued before this member is called, and then exits, leaving the calling member to process any output.
EQQWTSX3: Is an example of a process queueing commands to the stack before calling EQQWTSO3, which manages the Workload Automation Programming Language environment setup, and then processes the output when EQQWTSO3 completes.
EQQWTSX4: Is an example of a process queueing commands to the stack before calling EQQWTSO4, which assumes that the Workload Automation Programming Language environment is already set up, and then processes the output when EQQWTSO4 completes.