Half-duplex conversation states

The following half-duplex conversation states are defined:

RESET is the initial state in which the application program can allocate a conversation. There are no state transitions to the RESET state.
SEND is the state in which the application program can send data, request confirmation, or request sync point.
RECEIVE is the state in which the application program can receive information from the remote transaction program.
CONFIRM is the state in which the application program can reply to a confirmation request and includes the actual states of RECEIVE_CONFIRM, RECEIVE_CONFIRM_SEND, and RECEIVE_CONFIRM_DEALLOCATE.
PEND_END_CONV_LOG is the state in which the application program can receive error log data that immediately precedes the end of the conversation. (Error log data can also be received by the application program when the conversation is in RECEIVE state, but in that case the log data does not immediately precede the end of the conversation.) The PEND_END_CONV_LOG state is entered only when a conversation has ended and there is error log data to be received by the application.
PEND_RCV_LOG is the state in which the application program can receive error log data that does not immediately precede the end of the conversation.
PEND_SEND is the state in which the conversation is placed when data and a change-direction indicator are both returned on an APPCCMD CONTROL=RECEIVE macroinstruction. This state is transient, but you can display it with MODIFY DISPLAY. Look at the CD indicator to determine whether a response was sent. If the conversation is in PEND_SEND state, only an FMH-7 is sent.
PENDING_ALLOCATE is the state in which the conversation is placed when the application issues the APPCCMD CONTROL=PREALLOC macroinstruction. The conversation remains in PENDING_ALLOCATE until the application issues the APPCCMD CONTROL=SENDFMH5 macroinstruction.
END_CONV is the state in which the conversation is placed when the conversation is being deallocated. This state is transient. Although you might be able to see it by using MODIFY DISPLAY, once it completes the conversation ID is returned to the conversation pool for reuse.
PEND_DEALL is the state in which the conversation is placed when the application issues the APPCCMD CONTROL=DEALLOC, QUALIFY=CONFIRM|DATACON macroinstruction. If the partner LU sends a positive reply, the conversation is placed in END_CONV state. If the partner LU sends a negative reply, the conversation is placed in RECEIVE state.

Note: SYNC_POINT, SYNC_POINT_SEND, SYNC_POINT_DEALLOCATE, DEFER_RECEIVE, DEFER_DEALLOCATE, DEALLOCATE, and BACKOUT_REQUIRED are not maintained by VTAM® LU 6.2.

The state of the conversation determines the APPCCMD that the application is allowed to issue. Table 1 correlates the APPCCMD and its CONTROL and QUALIFY settings to the half-duplex conversation states. For each APPCCMD and state, a "yes," "no," or "n⁄a" is indicated.

yes: The application program is allowed to issue the APPCCMD when the conversation is in that state.
no: The application program cannot issue the APPCCMD when the conversation is in that state. An APPCCMD issued for a conversation in a disallowed state completes with a return code indicating STATE_ERROR.
n⁄a: The state is not applicable either because it cannot exist at the time the APPCCMD is issued or because it is not relevant to the APPCCMD.

Table 1. Correlation of basic conversation macroinstructions to half-duplex conversation states
APPCCMD CONTROL= ,QUALIFY=	RESET	SEND	RECEIVE	CONFIRM	PEND END CONV LOG	PEND RCV LOG	PEND SEND	PEND ALLOC
DEALLOC, ABNDnnnn	n/a	yes	yes	yes	yes	yes	yes	yes
DEALLOC, CONFIRM	n/a	yes	no	no	no	no	yes	no
DEALLOC, DATACON	n/a	yes	no	no	no	no	yes	no
DEALLOC, DATAFLU	n/a	yes	no	no	no	no	yes	no
DEALLOC, FLUSH	n/a	yes	no	no	no	no	yes	no
DEALLOCQ, ABNDnnnn	n/a	yes	yes	yes	yes	yes	yes	yes
PREPRCV	n/a	yes	no	no	no	no	yes	no
RCVEXPD, ANY ¹	n/a	yes	yes	yes	yes	yes	yes	no
RCVEXPD, IANY ¹	n/a	yes	yes	yes	yes	yes	yes	no
RCVEXPD, ISPEC	n/a	yes	yes	yes	yes	yes	yes	no
RCVEXPD, SPEC	n/a	yes	yes	yes	yes	yes	yes	no
RECEIVE, ANY ²	n/a	n/a	yes	n/a	n/a	n/a	n/a	no
RECEIVE, IANY ²	n/a	n/a	yes	n/a	n/a	n/a	n/a	no
RECEIVE, ISPEC	n/a	no	yes	no	yes	yes	no	no
RECEIVE, SPEC	n/a	yes	yes	no	yes	yes	yes	no
REJECT, CONV	n/a	yes	yes	yes	yes	yes	yes	yes
RESETRCV	n/a	yes	yes	yes	yes	yes	yes	no
SEND, CONFIRM	n/a	yes	no	no	no	no	yes	no
SEND, CONFRMD	n/a	no	no	yes	no	no	no	no
SEND, DATA	n/a	yes	no	no	no	no	yes	no
SEND, DATACON	n/a	yes	no	no	no	no	yes	no
SEND, DATAFLU	n/a	yes	no	no	no	no	yes	no
SEND, ERROR	n/a	yes	yes	yes	no	yes	yes	no
SEND, FLUSH	n/a	yes	no	no	no	no	yes	no
SEND, RQSEND	n/a	yes	yes	yes ³	no	no	no	no
SENDEXPD, DATA ⁴	n/a	yes	yes	yes	yes	yes	yes	no
SENDFMH5	n/a	n/a	no	no	no	no	no	yes

APPCCMD CONTROL=RCVFMH5, APPCCMD CONTROL=PREALLOC, and CONTROL=ALLOC cannot be issued against a specific conversation and therefore are not included in Table 1. APPCCMD CONTROL=CHECK is also not included because it cannot cause a state error to occur. It causes the application program to synchronously wait until a previously-issued asynchronous APPCCMD completes. Because APPCCMD CONTROL=CHECK is issued against a prior APPCCMD, any state errors that occur would have been detected when the prior macroinstruction was issued. APPCCMD CONTROL=TESTSTAT is not included because it cannot cause a state error to occur. Its processing does not alter the conversation.