Communicating with IBM Z Workload Scheduler

To establish communication with IBM Z Workload Scheduler, 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 IBM Z Workload Scheduler. For GET, PUT, and DEL requests, the LU that the ATP sends requests to (the target LU) must be owned by the Z controller. For CREATE requests, if the target LU is not owned by an IBM Z Workload Scheduler 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 IBM Z Workload Scheduler in a send buffer. IBM Z Workload Scheduler 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, IBM Z Workload Scheduler 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.