CPI-C Accept_Conversation (cmaccp) Does Not Block As Expected
Article ID: 184505
Article Last Modified on 3/8/2005
APPLIES TO
- Microsoft SNA Server 2.0
- Microsoft SNA Server 2.1
- Microsoft SNA Server 3.0
- Microsoft SNA Server 3.0 Service Pack 4
- Microsoft SNA Server 4.0
This article was previously published under Q184505
SYMPTOMS
If a CPI-C (Common Programming Interface for Communications) application
calls WinCPICStartup followed by Accept_Conversation (cmaccp), then the
cmaccp() will function in blocking mode. However, the cmaccp() will never
complete, because no local TP (transaction processing) name has been
specified for the application.
In order to associate a TP (Transaction Program) name with the cmaccp()
call, Specify_Local_TP_Name (cmsltp) must be called prior to cmaccp().
However, this causes cmaccp() to function in "non-blocking" mode. This can
cause the cmaccp() to fail immediately with an error 25
(CM_PROGRAM_STATE_CHECK) instead of waiting for an incoming attach request.
CAUSE
This behavior is by design, according to the Windows CPI-C specification.
RESOLUTION
To force blocking behavior of cmaccp, Wait_For_Conversation (cmwait) must
be called after cmsltp() and cmaccp() in order to cause the application's
thread to block. All CPI-C functions operate in blocking mode by default,
except the cmaccp() function, which requires the application to call
cmwait() in order to force blocking behavior.
There are no plans to change the Windows CPI-C specification or to modify
the SNA Server CPI-C API (application programming interface) to behave
differently than it does in the current design.
Keywords: kbprb KB184505