|
|
|
|
The APPC verbs MC_RECEIVE_AND_POST and RECEIVE_AND_POST enable a TP to receive data asynchronously, without regard for other events occurring within the program. Therefore, the program can perform other tasks while receiving data.
For Solaris systems, the parameters for [MC_]RECEIVE_AND_POST include the address of a callback routine, which APPC uses to inform the TP when data has been received. This callback routine is independent of the callback routine supplied on the asynchronous APPC entry point. [MC_]RECEIVE_AND_POST may be issued using either the synchronous or the asynchronous entry point; APPC uses the callback routine supplied in the verb parameters to return received data to the TP and uses the callback routine supplied to the asynchronous entry point only if a null address is supplied in the VCB.
On Win32 systems, verb completion is by signaling an event handle provided by the application. The sema parameter contains the event handle (obtained by calling either the Windows CreateEvent or OpenEvent functions), which APPC uses to inform the TP when data has been received.
The operation of [MC_]RECEIVE_AND_POST is similar to the operation of [MC_]RECEIVE_AND_WAIT issued using the asynchronous entry point; control returns to the application immediately, and the requested data is subsequently returned on the callback routine. The main difference is that issuing [MC_]RECEIVE_AND_POST puts the conversation into a defined state, Pending-Post state, in which the TP can issue a limited range of APPC verbs on this conversation while waiting for the callback routine to be called. The verbs that can be issued in Pending-Post state are:
GET_TYPE
[MC_]DEALLOCATE with a deallocate type of
[MC_]GET_ATTRIBUTES
[MC_]REQUEST_TO_SEND
[MC_]SEND_ERROR
[MC_]TEST_RTS
TP_ENDED
If the application issues [MC_]RECEIVE_AND_WAIT (or any other APPC verb) using the asynchronous entry point, it must not issue any other APPC verbs on this conversation until the callback routine has been called.
In Receiving Data Asynchronously, the invoked TP receives data asynchronously.
| State | Invoking TP | Flow | Invoked TP | State |
| TP_STARTED | ||||
| Reset | ||||
| MC_ALLOCATE | ||||
| Send | ||||
| MC_FLUSH | ||||
| -> | ||||
| Reset | ||||
| RECEIVE_ALLOCATE | ||||
| Receive | ||||
| MC_RECEIVE_AND_POST (primary_rc =AP_OK) | ||||
| Pending-Post | ||||
| (TP performs other tasks or issues verbs such as Request to Send or Get Attributes. Most other APPC verbs cannot be used in this conversation state (see APPC State Changes for information about permitted verbs). | ||||
| MC_SEND_DATA | ||||
| MC_DEALLOCATE | ||||
| Reset | ||||
| TP_ENDED | ||||
| -> | ||||
| Data is received. APPC calls the supplied callback routine. | ||||
| MC_RECEIVE_AND_POST returns primary_rc =AP_OK, what_rcvd= AP_DATA_COMPLETE | ||||
| Receive | ||||
| (TP checks that the callback routine has been called.) | ||||
| MC_RECEIVE_AND_WAIT (primary_rc =AP_DEALLOC_NORMAL) | ||||
| Reset | ||||
| TP_ENDED | ||||
In Receiving Data Asynchronously, the invoked TP follows these steps to receive data asynchronously:
Issues the MC_RECEIVE_AND_POST verb. One of the parameters is the address of the callback routine which APPC calls (on Solaris)or event handle which APPC signals (on Windows) when the data is received.
Verifies that the primary_rc (primary return code) is AP_OK, which indicates that the TP has begun to receive data asynchronously.
Performs tasks not related to this conversation while receiving data asynchronously. Most APPC verbs are not valid in this conversation state.
Waits for the callback routine to be called (on Solaris), or event handle to be signaled (on Windows), which indicates that the TP has finished receiving data asynchronously.
Verifies the primary_rc of the MC_RECEIVE_AND_POST verb again. The second primary_rc indicates whether the data was received without error.
Verifies that the what_rcvd parameter of the MC_RECEIVE_AND_POST verb is AP_DATA_COMPLETE.
Issues the MC_RECEIVE_AND_WAIT verb to receive the deallocation indicator.
The [MC_]RECEIVE_AND_POST verb returns the primary_rc and secondary_rc parameters twice; first after issuing the verb, to indicate whether or not the verb has successfully begun to wait for data, and second after the data has been received.
After the invoked TP issues the MC_RECEIVE_AND_POST verb and gets a primary_rc of AP_OK, the conversation changes to Pending-Post state.
When the TP has finished receiving data asynchronously and APPC calls the supplied callback routine (on Solaris) or signals the supplied event handle (on Windows), the conversation changes to Receive state because the what_rcvd parameter contains AP_DATA_COMPLETE.
|
|
|
 |
|