Asynchronous Processing

Asynchronous processing provides a means of distributing the processing that is required by an application between systems in an intercommunication environment. Unlike distributed transaction processing, however, the processing is asynchronous.

In distributed transaction processing, a session is held by two transactions for the period of a "conversation" between them, and requests and replies can be directly correlated.

In asynchronous processing, the processing is independent of the sessions on which requests are sent and replies are received. No direct correlation can be made between a request and a reply, and no assumptions can be made about the timing of the reply.

In general, asynchronous processing is applicable to any situation in which it is not necessary or desirable to tie up local resources while a remote request is being processed.

Asynchronous processing is not suitable for applications that involve synchronized changes to local and remote resources; for example, it cannot be used to process simultaneous linked updates to data split between two systems.

Asynchronous processing methods

In XCICS, asynchronous processing can be done in either of two ways:

You can use the START command to schedule a transaction in a remote system in much the same way as you would in a single XCICS system. This type of asynchronous processing is in effect a form of XCICS function shipping, and as such, it is transparent to the application. The systems programmer determines whether the attached transaction is local or remote.

If you use the START command for asynchronous processing, you can communicate only with systems that support the special protocol needed for function shipping; that is, XCICS itself and CICS.

An XCICS transaction that is initiated by a remotely-issued start request can use the RETRIEVE command to retrieve any data associated with the request. Data transfer is restricted to a single record passing from the initiating transaction to the transaction initiated.

This is a cross-system method and has no single-system equivalent. You can use it to initiate a transaction in a remote system that supports one of the DTP protocols.

When you use DTP to attach a remote transaction, you also allocate a session and start a conversation. This permits you to send data directly and, if you want, to receive data from the remote transaction. Your transaction design determines the format and volume of the data you exchange. For example, you can use repeated SEND commands to pass multirecord files.

When you have exchanged data, you terminate the conversation and quit the local transaction, leaving the remote transaction to run on independently.

Whatever protocol you decide to use, you must observe the rules it imposes. However short the conversation, during the time it is in progress, the processing is synchronous. In terms of command sequencing, error recovery, and syncpointing, it is full DTP.

In both forms of asynchronous processing (and also in synchronous processing), an XCICS transaction can use the EXEC CICS ASSIGN STARTCODE command to determine how it was initiated.

Asynchronous processing programming

The interval control commands that can be used for asynchronous processing are:

For further information, please refer to the XCICS Programming Guide.