Communication states

Clients and servers that use LU 6.2 and TCP/IP to communicate with each other are said to be in one of three communication states:

At any given time, communication between the mainframe server and the client is in only one direction. The mainframe server can send information to a client or receive information from a client, but not both.

The mainframe server must be in the correct communication state before it can execute certain functions. For example, it must be in SEND state to send results or messages; it must be in RECEIVE state to retrieve requests.

The communication state of the mainframe server is set by the Gateway-Library functions. For example, after it accepts a client request with TDACCEPT, an application switches to SEND state, because the next communication it has with the client is to send results. In most cases, the required communication state is evident from the name of the function. The reference pages in Chapter 3, “Functions” explain which state is required for each function.

After a client request is processed and all results returned, an application calls TDSNDDON. If the transaction processes only a single client request (a short transaction), TDSNDDON ends communication with the client. If the transaction is a long-running transaction that finished one client request and is awaiting another, TDSNDDON keeps communication open and switches the communication state from SEND to RECEIVE. See “Long-running transactions” for details about this type of transaction.

When you follow the usual sequence of function calls, the mainframe server is always in the correct state. To check the communication state before issuing a function call, call TDSTATUS. If your application tries to execute a function when the mainframe server program is not in the appropriate communication state, the operation fails, and the return code indicates that the application is in the wrong state.