Cancelling RECEIVE_AND_WAIT Using DEALLOCATE(ABEND) Hangs

• Microsoft SNA Server for Windows NT, versions 2.0, 2.1, 2.11, and 3.0

SYMPTOM

If you are an application programmer and you cancel an outstanding APPC [MC_]RECEIVE_AND_WAIT call, using [MC_]DEALLOCATE with dealloc_type set to an AP_ABEND option, the DEALLOCATE call hangs.

This symptom occurs sporadically.

CAUSE

The conversation is in a receive state, and SNA Server cannot send the deallocate message to the remote computer until it has been granted the direction indicator on the conversation from the remote computer.

This problem occurs due to the half-duplex and cooperative nature of APPC. In general, if an APPC Transaction Program (TP) wants to send some data (or a DEALLOCATE verb), the program must wait until the other computer gives it direction to send. The exception to this is if the other computer is in the middle of sending data. Then it is possible to issue a DEALLOCATE, because it is possible to send a negative response to the next RU from the other computer.

RESOLUTION

If a conversation is in a receive state and the program is not in the middle of receiving data, you need to take one of the following, more drastic steps to end a conversation:

• Cancel the pending RECEIVE_AND_WAIT. Then, use the REQUEST_TO_SEND verb to change the conversation to a send state, and then issue the DEALLOCATE verb.

  -or-

• Using the APPC interface, issue TP_ENDED(type=AP_HARD). This ends the TP, along with all conversations associated with that TP. The program does not need the direction indicator, because this terminates the session. Using the CPIC API, the cmcanc() verb cancels the conversation. This also terminates the session, and so does not have to worry about obtaining direction.