Managing the status of the HCL Workload Automation Agent workstation in the plan

Use the WSSTAT command when you want to:

Change the status of an HCL Workload Automation Agent workstation in the current plan.
Verify if the communication between the HCL Workload Automation Agent workstation and the controller is active.

You use WSSTAT on HCL Workload Automation Agents in the same way as you do with any other computer automatic workstation.

The status information is communicated to the controller to indicate that a workstation is in one of the following states:

ACTIVE: The workstation is running and scheduling its own plan.
OFFLINE: Communication is lost between the controller and the HCL Workload Automation Agent workstation on the system that the workstation represents. The HTTP client retries to establish the connection until it is successful.
FAILED: You manually set the workstation status to FAILED.

When you run the WSSTAT command, you can optionally define restart and routing options for the workload defined on the workstation when you are reporting a status of OFFLINE or FAILED.

You can invoke WSSTAT as a TSO command or by using a batch job which runs program EQQEVPGM. If you invoke WSSTAT as a TSO command, you must allocate the EQQMLIB data set to the address space of the TSO user, either by adding DD statements to the logon procedure, or by using the ALLOC command after TSO logon. In the TSO environment, error messages and trace records are sent directly to the terminal user. Messages are not delivered to indicate successful command execution.

Use of the WSSTAT command can be restricted with fixed resource code RL and subresource RL.WSSTAT. The authority of the requester is verified by the subsystem name identified in the command if an AUTHDEF statement is defined for that subsystem. When SUBSYS(MSTR) is specified, all tracker subsystems defined on the z/OS® system where the WSSTAT command is issued attempt to verify the authority of the requester before an event is generated. A requester might be rejected by one subsystem and accepted by another.

The subsystem to which you direct the command need not be active when the command is issued. An event is generated and queued in CSA together with other job-tracking events. If the subsystem is not active when the command is issued, the authority of the requester is verified using the class name specified in the AUTHDEF statement when the subsystem was last started. If the subsystem has not been started since a z/OS® IPL, no authority verification can be performed.

Note: If you used the panels to set the status of a workstation to OFFLINE, you cannot reset it to ACTIVE with WSSTAT.