Cancelling RECEIVE_AND_WAIT Using DEALLOCATE(ABEND) Hangs
ID: Q136792
|
The information in this article applies to:
-
Microsoft SNA Server, versions 2.0, 2.1, 2.11, 3.0
on the following platforms: NT
SYMPTOMS
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.
Additional query words:
prodsna
Keywords : kbnetwork kbprg ntnetserv
Version : WINDOWS:2.0,2.1,2.11,3.0
Platform : WINDOWS
Issue type :