Communicating with HCL Workload Automation for Z

To establish communication with HCL Workload Automation for Z, your ATP must initialize and then allocate a conversation. The ATP must supply all information that is required to initialize the conversation; for example, the partner transaction program (TP) name and its LU, and a user ID and password that is used for security checking. Supply TP name EQQAPI to communicate with HCL Workload Automation for Z. For GET, PUT, and DEL requests, the LU that the ATP sends requests to (the target LU) must be owned by the controller. For CREATE requests, if the target LU is not owned by an HCL Workload Automation for Z address space where an event writer task is started, the ATP must send requests so that the events are broadcast on the target z/OS system. Broadcasting events describes how you broadcast events on the target system.

When communication is established, your ATP sends a request to HCL Workload Automation for Z in a send buffer. HCL Workload Automation for Z responds by issuing a receive, inviting more requests from your ATP while it is processing the request. When you have completed your requests, you should issue several receive requests to ensure all data is received by the ATP. In cases where the receive type is Receive_Immediate, or if the buffers are large, data is returned in packets.

When the request has been processed, HCL Workload Automation for Z builds a buffer that is sent to your ATP the next time that the ATP issues a receive request. This buffer is called a receive buffer.

If there is more than one active request from your ATP at a given time, you can identify each request by setting the token field (APPTOKEN in the APP section) to a unique value. The value could be, for example, a time stamp.

You can continue to make requests while the conversation is established. When you want to end the conversation, your ATP must issue a deallocate verb.