Queued Programs

Queued programs can start in one of two ways:

Attach manager started: The program is started by the attach manager.

Operator started: The program is to be started by another program in the workstation or by an operator.

The attach manager maintains two queues for each queued transaction program name in the defined transaction program list. One queue is for incoming allocation requests; the other is for RECEIVE_ALLOCATE verbs. For example, when an incoming allocation request arrives, the attach manager starts the corresponding local program or sends a message to the operator. The node holds the incoming allocation request until the program that the attach manager started issues a matching RECEIVE_ALLOCATE verb or until a timeout occurs. The node uses the value configured for the incoming_alloc_timeout parameter to determine when time-outs occur. Other allocation requests can arrive for that transaction program or for another transaction program. The other programs wait in their respective queues until a matching RECEIVE_ALLOCATE verb is issued, or until they time out.

Local programs can issue RECEIVE_ALLOCATE verbs before any matching allocation request arrives. The attach manager holds the RECEIVE_ALLOCATE verb on its respective queue and waits for an allocation request to arrive from a partner LU. Each queue has a timeout value; the rcv_alloc_timeout parameter specifies how long a RECEIVE_ALLOCATE verb can wait on a queue before the verb times out. The attach manager returns queued RECEIVE_ALLOCATE verbs to the associated programs with an ALLOCATE_NOT_PENDING return code. The timeout value for RECEIVE_ALLOCATE verbs can be 0 to enable programs to check whether any allocation requests are queued, and, if not, to continue other processing.

The RECEIVE_ALLOCATE verb can be issued as a nonblocking verb. This enables the transaction program to service multiple conversations from a single thread in a single process.

When RECEIVE_ALLOCATE is issued as a nonblocking verb, the attach manager returns control to the transaction program immediately; the transaction program need not remain in a wait state while waiting for the matching incoming allocation request to arrive. Instead, the transaction program can perform other work, and choose when to wait for the matching incoming allocation request.

The transaction program can queue multiple nonblocking RECEIVE_ALLOCATE verbs for different conversations. The maximum number of verbs that can be queued is limited only by resource constraints. A nonblocking RECEIVE_ALLOCATE verb will remain on the attach manager’s RECEIVE_ALLOCATE verb queue until either the matching allocation request arrives or the verb times out, that is, the rcv_alloc_timeout value has been reached.

The attach manager saves the information that identifies the transaction program when a queued program issues a valid RECEIVE_ALLOCATE verb call for a transaction program. When the queued program ends, the attach manager examines the queue of allocation requests for that transaction program. If the queue is not empty, the attach manager starts a new instance of the program, or sends a message that directs the operator to start the program.

You should configure the maximum size of the incoming allocation request queue for each transaction program. Resource constraints limit the number of queued RECEIVE_ALLOCATE verbs.

The following two cases summarize queued operations:

Case 1:: One or more incoming allocation requests arrive before a RECEIVE_ALLOCATE verb or CPI Communications CMACCP call is issued for a given transaction program. The attach manager queues the incoming allocation requests (for a time specified by a configured timeout value) until a RECEIVE_ALLOCATE verb is issued. The first incoming allocation request satisfies the RECEIVE_ALLOCATE verb.
Case 2:: A RECEIVE_ALLOCATE verb is issued before an incoming allocation request arrives for a given transaction program. The attach manager queues the RECEIVE_ALLOCATE verb (for a time specified by a configured timeout value) until an incoming allocation request arrives. In certain cases, more than one RECEIVE_ALLOCATE verb might be issued and queued before an incoming allocation request arrives. Each new incoming allocation request satisfies the next RECEIVE_ALLOCATE verb in the queue.

Table 1 provides a summary of the verbs and incoming allocation requests associated with queued and dynamic load parameter values.

Table 1. Verb Processing and Transaction Program Name Configuration
Verb Processing	Transaction Program Operation
Verb Processing	Nonqueued—attach manager started	Operator started	Queued—attach manager started
Incoming allocation request with pending RECEIVE_ALLOCATE verb.	Cannot occur; no queue of pending RECEIVE_ALLOCATE verbs.	OK RECEIVE_ALLOCATE verb.	OK RECEIVE_ALLOCATE verb.
Incoming allocation request without pending RECEIVE_ALLOCATE verb.	Load and execute another program instance. Hold incoming allocation request. Wait for RECEIVE_ALLOCATE verb.	Put incoming allocation request on queue unless queue is full. Wait for RECEIVE_ALLOCATE verb or for allotted time to expire.	If program is not started, load and execute it. Put incoming allocation request on queue unless queue is full. Wait for RECEIVE_ALLOCATE verb or for allotted time to expire.
RECEIVE_ALLOCATE verb with incoming allocation request pending.	OK RECEIVE_ALLOCATE verb.	OK RECEIVE_ALLOCATE verb.	OK RECEIVE_ALLOCATE verb.
RECEIVE_ALLOCATE verb with no pending incoming allocation request.	Cannot occur; pending allocation requests for nonqueued operations cannot run out of time.	Hold RECEIVE_ALLOCATE verb. Wait for incoming allocation request or for allotted time to expire.	Hold RECEIVE_ALLOCATE verb. Wait for incoming allocation request or for the allotted time to expire.
Transaction program operation ends.	Nothing happens.	Nothing happens.	If there is a pending allocation request, reload the program; otherwise, reload on the next incoming allocation request.