There are two forms of half-duplex communication: half-duplex flip-flop communication and half-duplex contention communication. In half-duplex flip-flop communication, one session partner is designated in the session parameters as the first to send a normal-flow request after a session is established; thereafter, the program and the LU notify each other, in turn, by sending a change-direction indicator whenever the other side can begin sending normal-flow requests. In half-duplex contention communication, after the session has been established, the application program and the LU can both attempt to start sending a normal-flow request at the same time (called contention). The one that is allowed to proceed is the one that was designated in the session parameters as the one that would always win in a contention situation. Similarly, in contention communication, when either session partner finishes sending a chain of normal-flow requests, both session partners can attempt at the same time to start sending a new request. Again, the winner of the contention is the one designated as such in the session parameters.

One bit in the common protocol portion of the session parameters controls priority for initial sending in half-duplex communication. One setting of the bit indicates that the PLU has priority for sending; that is, in half-duplex flip-flop communication, the PLU is the first to send a normal-flow request in the session, or is the first to send a normal-flow request after a Clear request. Another bit in the common protocol portion of the session parameters governs whether the PLU or the SLU wins in a half-duplex contention race in which both try to send at the same time.

Change-direction protocol must be used in half-duplex flip-flop communication; the protocol can optionally be used in half-duplex contention communication.

Change-direction protocol works like this: The LU that is the first to send continues sending normal-flow requests until it reaches the end of the data it wants to send. In the last request of the last chain it sends, the sender turns on the change-direction indicator (CD). (A VTAM® application program does this by issuing SEND CHNGDIR=CMD.) Upon receipt of this CD request, the other LU then sends normal-flow requests until it relinquishes its ability to send by including the CD in the last request of a chain.

Communication continues to alternate in this fashion indefinitely, as shown in Figure 1.

Figure 1. Change-direction protocol

While the receiver is awaiting CD, it can transmit to its session partner a Signal data-flow-control request with a Signal code that requests that CD be sent.

The LU that is awaiting CD (like the LU that has been quiesced in quiesce protocol) is prohibited only from sending normal-flow request traffic. It is free to send responses and expedited-flow requests.

As mentioned previously, VTAM does not enforce the change-direction protocol. Should the side waiting for CD begin sending data anyway, VTAM does not prevent the transmission. Compliance with the change-direction protocol is entirely the responsibility of the application program and the LU.