|
|
|
|
This section does not apply to Java CPI-C. Java CPI-C functions always operate in blocking mode; that is, the function does not return control to the application until the requested processing has completed.
By default, CPI-C functions operate in blocking mode; that is, the function does not return control to the application until the requested processing has completed. For example, the Confirm function does not return until CPI-C has sent a confirmation request to the partner application and received either an OK or an error response from it.
CPI-C functions can also operate in nonblocking mode; that is, the function returns control to the application immediately, even if the requested processing has not yet completed. This enables the application to continue with other processing that is not related to this conversation, and obtain the results of the verb processing at a later stage.
The application can use the function Check_For_Completion to determine whether a previous nonblocking function has now completed, or Wait_For_Conversation to wait for it to complete. Nonblocking Operation shows an example of the use of nonblocking mode.
The following steps explain the processing shown in the previous example.
After allocating the conversation and sending some data, the
invoking program issues Set_Processing_Mode to set the processing mode to
The invoking program then issues Confirm, which returns CM_OPERATION_INCOMPLETE. This indicates that the function was issued successfully and is operating in nonblocking mode.
The program can now perform other processing not related to this conversation, including issuing CPI-C functions on other conversations. It can also issue a limited range of CPI-C functions on this conversation (such as the Extract_* functions). This is different from the IBM CPI-C 2.0 specification, in which the program cannot issue any functions on this conversation other than Wait_For_Conversation or Cancel_Conversation.
At some later time, the program issues Wait_For_Conversation to wait for the previous nonblocking function to complete. Since the partner program has not yet issued Confirmed, processing for the previous Confirm function has not completed, so the invoking program is suspended.
When the partner program issues Confirmed, this completes the processing of the invoking program's Confirm function. The Wait_For_Conversation function then returns. The return_code of CM_OK indicates that Wait_For_Conversation completed successfully; the conversation return_code of CM_OK indicates that the Confirm function (for which it was waiting) completed successfully.
After sending additional data, the invoking program then issues Deallocate, which returns CM_OPERATION_INCOMPLETE. This indicates that the function was issued successfully and is operating in nonblocking mode. As before, the program can now perform other processing not related to this conversation, but cannot issue most CPI-C functions on this conversation.
The partner program receives the Deallocate request and replies with Confirmed. This completes the processing for the Deallocate function.
The invoking program issues Check_For_Completion, to determine whether any previous nonblocking functions on any of its conversations have completed. Since the Deallocate processing has already completed, Check_For_Completion returns with the conversation_ID of this conversation.
The program then issues Wait_For_Conversation, to get the result of the Deallocate processing. This returns immediately because the Deallocate processing has already completed.
The application should use the Specify_Windows_Handle function before issuing any verbs in nonblocking mode. This function specifies a Windows handle to which CPI-C sends a message when the verb processing has completed. This message notifies the application that the verb has completed; there is no need for the application to issue an additional call to wait for the results of the verb processing.
CPI-C can use an alternate method to indicate the verb has completed-signaling an event handle. If the application registers an event with the conversation using WinCPICSetEvent, then the application can call the Win32 functions WaitForSingleObject or WaitForMultipleObjects to wait to be notified of the completion of the verb.
If the outstanding call is a Receive call, the application can issue the following calls while Receive is outstanding:
Request_To_Send
Send_Error
Test_Request_to_Send_Received
Cancel_Conversation
Deallocate
As an alternative to using Specify_Windows_Handle or WinCPICSetEvent as described previously, the application can use Wait_For_Conversation, as for Solaris systems. This function is provided for Windows systems to assist in migrating applications from other operating system environments. However, the use of blocking functions such as Wait_For_Conversation in the Windows environment is strongly discouraged. If you are writing a new application specifically for the Windows environment, use Specify_Windows_Handle and not Wait_For_Conversation.
Check_For_Completion, described previously for Solaris systems, is not supported on Windows systems.
If the application uses one of the calls listed previously in nonblocking mode while Receive is outstanding, it must use Specify_Windows_Handle. It must not issue Wait_For_Conversation if another call is outstanding in addition to Receive; the results of this call are undefined if more than one call is outstanding on the same conversation.
|
|
|
 |
|