Asynchronous processing using START/RETRIEVE commands

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

Starting and canceling remote transactions

The interval control START command is used to queue a transaction-initiation request in a remote CICS® system. The command is effectively function shipped. In the remote system, the mirror transaction is invoked to issue the START command.

You can include time-control information on the shipped START command, using the INTERVAL or TIME option. Before a command is shipped, a TIME specification is converted by CICS to a time interval relative to the local clock. If the ends of a link are in different time zones, use the INTERVAL option.

The time interval specified in a START command is the time at which the remote transaction is to be initiated, not the time at which the request is to be shipped to the remote system.

A START command shipped to a remote CICS system can be canceled, before the expiry of the time interval, by shipping a CANCEL command to the same system. The START command to be canceled is uniquely identified by the REQID value specified on the START command and on the associated CANCEL command. Any task can issue the CANCEL command.

Passing information with the START command

The START command has a number of options that enable information to be made available to the remote transaction when it is started. If the remote transaction is in a CICS system, the information is obtained by using the RETRIEVE command. The information that can be specified is summarized in the following list:

Passing an APPLID with the START command

If you have a transaction that can be started from several different systems, and that is required to issue a START command to the system that initiated it, you can arrange for each invoking transaction to send its local system APPLID as part of the user data in the START command. A transaction can obtain its local APPLID by using an ASSIGN APPLID command.

Improving performance of intersystem START requests

In some inquiry-only applications, sophisticated error-checking and recovery procedures may not be justified. When the transactions make inquiries only, the terminal operator can retry an operation if no reply is received within a specific time. In such a situation, the number of data flows to and from the remote system can be substantially reduced by using the NOCHECK option of the START command. When the connection between the two systems is through VTAM®, this can result in considerably improved performance. The trade-off is between performance and sophisticated recovery procedures.

A typical use for the START NOCHECK command is in the remote inquiry application described in Example.

The transaction attached as a result of the terminal operator’s inquiry issues an appropriate START command with the NOCHECK option, which causes a single message to be sent to the appropriate remote system to start, asynchronously, a transaction that makes the inquiry. The command should specify the operator’s terminal identifier. The transaction attached to the operator’s terminal can now terminate, leaving the terminal available for either receiving the answer or initiating another request.

The remote system performs the requested inquiry on its local database, then issues a start request for the originating system. This command passes back the requested data, together with the operator’s terminal identifier. Again, only one message passes between the two systems. The transaction that is then started in the originating system must format the data and display it at the operator’s terminal.

If a system or session fails, the terminal operator must reenter the inquiry, and be prepared to receive duplicate replies. To aid the operator, either a correlation field must be shipped with each request, or all replies must be self-describing.

An example of intercommunication using the NOCHECK option is given in Figure 10.

The NOCHECK option is always required when shipping of the START command is queued pending the establishment of links with the remote system (see Local queuing of START commands for remote transactions).

Including start request delivery in a logical unit of work

The delivery of a start request to a remote system can be made part of a logical unit of work by specifying the PROTECT option on the START command. The PROTECT option indicates that the remote transaction must not be scheduled until the local one has successfully completed a synchronization point. (It can take the synchronization point either by issuing a SYNCPOINT command or by terminating.)

Successful completion of the syncpoint guarantees that the start request has been delivered to the remote system. It does not guarantee that the remote transaction has completed, or even that it will be initiated.

Deferred sending of START requests with NOCHECK option

For START commands with the NOCHECK option, CICS defers transmission of the request to the remote system.

START requests with NOCHECK are deferred until one of the following events occurs:

There are exceptions to the above rules:

The first, or only, start request transmitted from a transaction to a remote system carries the begin-bracket indicator; the last, or only, request carries the end-bracket indicator. Also, if any of the start requests issued by the transaction specifies PROTECT, the last request carries the syncpoint-request indicator. Deferred sending allows the indicators to be added to the deferred data, and thus reduces the number of transmissions required. The sequence of requests is transmitted within a single SNA bracket and all the requests are handled by the same mirror task.

Local queuing of START commands for remote transactions

When a local transaction is ready to ship a START command, the intersystem facilities may be unavailable, either because the remote system is not active or because a connection cannot be established. The normal CICS action in these circumstances is to raise the SYSIDERR condition. This can be avoided by using the NOCHECK option, and arranging for CICS to queue the request locally and forward it when the required link is in service.

If the required connection is out of service, CICS queues a START NOCHECK command for a remote transaction when two conditions are satisfied:

  1. The SYSID option is not coded in the START command
  2. The local definition of the transaction specifies LOCALQ(YES).

CICS on System/390 products support the XISLCLQ global user exit, which allows flexibility by enabling a user-written program to make a decision about local queueing, overriding the LOCALQ option.

Data retrieval by a started transaction

A CICS transaction that is started by a start request can get user data and other information associated with the request by using the RETRIEVE command.

In accordance with the normal rules for interval control, CICS queues a start request for a transaction that carries both user data and a terminal identifier if the transaction is already active and associated with the same terminal. During the waiting period, the data associated with the queued request can be accessed by the active transaction by using a further RETRIEVE command. Such an access automatically cancels the queued start request.

Thus, it is possible to design a transaction that can handle the data associated with multiple start requests. Typically, a long-running transaction could be designed to accept multiple inquiries from a terminal and ship start requests to a remote system. From time to time, the transaction could issue RETRIEVE commands to receive the replies, the absence of further replies being indicated by the ENDDATA condition.

The WAIT option of the RETRIEVE command can be used to put the transaction into a WAIT state pending the arrival of the next start request from the remote system. Overall application design should ensure that a transaction cannot get into a permanent wait state due to the absence of further start requests--for example, the transaction can be defined with a timeout interval. (Note that this option is not supported by CICS on Open Systems.)

Terminal acquisition by a remotely-initiated CICS transaction

When a CICS transaction is started by a start request that names a terminal (TERMID), CICS makes the terminal available to the transaction as its principal facility. It makes no difference whether the start request was issued by a user transaction in the local CICS system or was received from a remote system and issued by the mirror transaction.

Starting transactions

You can name a system, rather than a terminal, in the TERMID option of the START command.

If CICS finds that the "terminal" named in a start request is a system, it selects an available session to that system and makes it the principal facility of the started transaction. If no session is available, the request is queued until there is one.

Related concepts
Introduction to asynchronous processing
Example
Asynchronous processing methods
System programming considerations
Asynchronous processing example (with NOCHECK)
Related reference
CICS product communication support
[[ Contents Previous Page | Next Page Index ]]