Queue-Level Nonblocking

Personal Communications and Communications Server APPC API support queue-level nonblocking. This support is provided through the APPC entry point.

Nonblocking operation enables control to be returned to the application if processing of a verb cannot be completed immediately, so that the application can continue other processing until it is notified that the outstanding verb has completed. Queue-level nonblocking means that the application can issue nonblocking verbs for different queues and have the verbs processed simultaneously by Personal Communications. The application can also issue a succession of nonblocking verbs for a given queue without waiting for any of the verbs to complete.

Personal Communications and Communications Server maintain six queues for nonblocking verbs:
  • An allocate queue (one for each active transaction program)
  • A send/receive queue (one per conversation, half-duplex only)
  • A send queue (one per full-duplex conversation)
  • A receive queue (one per full-duplex conversation)
  • A send-expedited queue (one per conversation)
  • A receive-expedited queue (one per conversation)

All six queue types can hold an unlimited number of verbs. Nonblocking verbs are queued if another (blocking or nonblocking) verb is being processed by either the Personal Communicationsor Communications Server program. Verbs in an allocate queue are processed concurrently, whereas verbs in the other queues are processed one at a time, in the order in which they are received by either program.

The application notifies Personal Communications or Communications Server that it wants a verb to be processed in nonblocking mode by setting a flag in the opext field, AP_NON_BLOCKING. The application can supply an event handle with any nonblocking verb that is used to notify the application of asynchronous verb completion. This handle is passed to Personal Communications in the SECONDARY_RC field. If no handle is specified, the application is notified that the verb has completed when the next verb on that queue specifies that a handle completes.

It is guaranteed that all preceding verbs with no handle are complete when the event is signaled after completion of a verb on the same queue that does not specify a handle.

When a nonblocking verb returns the flag AP_OPERATION_INCOMPLETE_FLAG, it is set in the opext field.

The APPC verbs that can be issued in nonblocking mode on the allocate queue are:
  • (MC_)ALLOCATE
  • (MC_)SEND_CONVERSATION
The APPC verbs that can be issued in nonblocking mode on the send/receive queue are:
  • (MC_)CONFIRM
  • (MC_)CONFIRMED
  • (MC_)DEALLOCATE
  • (MC_)FLUSH
  • (MC_)PREPARE_TO_RECEIVE
  • (MC_)RECEIVE_AND_WAIT
  • (MC_)RECEIVE_IMMEDIATE
  • (MC_)SEND_DATA
  • (MC_)SEND_ERROR
The APPC verbs that can be issued in nonblocking mode on the send queue (for full-duplex conversations) are:
  • (MC_)DEALLOCATE
  • (MC_)FLUSH
  • (MC_)SEND_DATA
  • (MC_)SEND_ERROR
The APPC verbs that can be issued in nonblocking mode on the receive queue (for full-duplex conversations) are:
  • (MC_)RECEIVE_AND_WAIT
  • (MC_)RECEIVE_IMMEDIATE
The APPC verb that can be issued in nonblocking mode on the receive-expedited queue (for full-duplex conversations) is:
  • (MC_)RECEIVE_EXPEDITED_DATA
The APPC verbs that can be issued in nonblocking mode on the send-expedited queue are:
  • (MC_)REQUEST_TO_SEND
  • (MC_)SEND_EXPEDITED_DATA
The following APPC verbs are always processed asynchronously but are not associated with any queue:
  • (MC_)RECEIVE_AND_POST
  • (MC_)TEST_RTS_AND_POST
Personal Communications and Communications Server APPC verbs that cannot be issued in nonblocking mode (and are processed in blocking mode if the application sets the nonblocking flag) are:
  • (MC_)GET_ATTRIBUTES
  • GET_TP_PROPERTIES
  • GET_TYPE
  • RECEIVE_ALLOCATE
  • TEST_RTS
  • TP_ENDED
  • TP_STARTED
  • CNOS

An application cannot issue verbs in nonblocking mode for the send/receive queue or the send-expedited queue until an ALLOCATE or RECEIVE_ALLOCATE verb has returned successfully (Personal Communications returns AP_PARAMETER_CHECK, and AP_BAD_CONV_ID). The CANCEL_CONVERSATION cannot be issued until the conversation identifier is returned in an ALLOCATE or RECEIVE_ALLOCATE verb.

A nonblocking verb issued for the send/receive queue or the send-expedited queue, with another (blocking or nonblocking) verb currently outstanding on the same queue, is added to that queue, and is only processed when the outstanding verb has completed.

A blocking verb issued when any other verb (for the same conversation) is outstanding, is rejected by Personal Communications (with primary_rc AP_TP_BUSY). Note that RECEIVE_AND_POST is treated as a blocking verb in this respect, but TEST_RTS_AND_POST can be issued with other verbs outstanding on the same conversation (and is not placed in any of the nonblocking verb queues). A blocking verb issued when there are no verbs on the same queue is processed as normal even though there may be verbs on other queues. Note that TEST_RTS, GET_ATTRIBUTES, GET_STATE and GET_TYPE are not associated with a queue and may be executed at any time and will never return AP_TP_BUSY.