For programming information about CICS® interval control, see the CICS Application Programming Guide manual. The interval control commands that can be used for asynchronous processing are:
For information about canceling dynamically-routed START commands, see Canceling interval control requests.
The interval control START command is used to schedule transactions asynchronously in remote CICS and IMS™ systems. The command is function shipped. If the remote system is CICS, the mirror transaction is invoked in the remote system to issue the START command on that system.
For CICS-to-CICS communication, you can include time-control information on the shipped START command in the normal way, by means of the INTERVAL or TIME options. A TIME specification is converted by CICS to a time interval, relative to the local clock, before the command is shipped. Because the ends of an intersystem link may be in different time zones, it is usually better to think in terms of time intervals, rather than absolute times, for intersystem communication.
Note particularly that the time interval specified on a START command specifies 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 at any time up to its expiration time by shipping a CANCEL command to the same system. The particular START command has a unique identifier (REQID), which you can specify on the START command and on the associated CANCEL command. The CANCEL command can be issued by any task that "knows" the identifier.
Time control cannot be specified for START commands sent to IMS systems; INTERVAL(0) must be specified or allowed to take the default value. Consequently, start requests for IMS transactions cannot be canceled after they have been issued.
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, it obtains the information by issuing a RETRIEVE command. The information that can be specified is summarized in the following list:
This is the principal way in which data can be passed to the remote transaction.
For CICS-to-CICS communication, additional data can be made available in a transient data or temporary storage queue named in the QUEUE option. The queue can be on any CICS system that is accessible to the system on which the remote transaction is executed.
The QUEUE option cannot be used for CICS-to-IMS communication.
These options, whose values are set by the local transaction, provide the means for the remote transaction to pass a reply to the local system. (That is, the TRANSID and TERMID specified by the remote transaction on its reply are the RTRANID and RTERMID specified by the local system on the initial request.)
For CICS-to-CICS communication, this is the name of a terminal that is to be associated with the remote transaction when it is initiated. It may be that the terminal is defined on the region that owns the remote transaction but is not owned by that region. If so, it is obtained by the automatic transaction initiation (ATI) facility of transaction routing. See Traditional routing of transactions started by ATI.
The global user exits XICTENF and XALTENF can be coded to cover the case of the terminal that is shippable but not defined in the application-owning region. See Shipping terminals for automatic transaction initiation.
For CICS-to-IMS communication, it is a transaction code or an LTERM name.
If you have a transaction that can be started from several different systems, and which is required to issue a START command to the system that initiated it, you can arrange for all of the invoking transactions to send their local system sysid or applid as part of the user data in the START command. An initiating transaction can obtain its local sysid by using an ASSIGN SYSID command, or its applid by using an ASSIGN APPLID command.
If the name of the connection to the remote system matches the SYSIDNT system initialization parameter of the remote system (typical of MRO), then the started transaction can reply using a START command specifying the passed sysid.
If the name of an APPC or LUTYPE6.1 connection to the remote system does not match the SYSIDNT system initialization parameter of the remote, then the started transaction can still determine the sysid to be responded to. It can do this by issuing an EXTRACT TCT command on which the NETNAME option specifies the passed applid.
In many inquiry-only applications, sophisticated error-checking and recovery procedures are not justified. Where 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 messages to and from the remote system can be substantially reduced by using the NOCHECK option of the START command. Where the connection between the two systems is via VTAM®, this can result in considerably improved performance. The price paid for better performance is the inability of CICS to detect some types of error in the START command.
A typical use for the START NOCHECK command is in the remote inquiry application described at the beginning of this section.
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 13.
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), or if the request is being shipped to IMS.
The delivery of a start request to a remote system can be made part of a 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 (syncpoint). (It can take the syncpoint either by issuing a SYNCPOINT command or by terminating normally.)
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.
If the remote system is IMS, no message must cross the link between the START command and the syncpoint. Both PROTECT and NOCHECK must be specified for all IMS recoverable transactions.
For START commands with the NOCHECK option, whether or not PROTECT is specified, CICS may defer transmission of the request to the remote system, depending on the environment.
For MRO links, START requests with NOCHECK are not deferred.
For ISC links, START requests with NOCHECK are deferred until one of the following events occurs:
For both the APPC and LUTYPE6.1 protocols, if the first START with NOCHECK is followed by a second, CICS transmits the first and defers the second.
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 in the unit of work (UOW) 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, if the remote system is CICS, all the requests are handled by the same mirror task.
For IMS, no message must cross the link between a START request and the following syncpoint. Therefore, you cannot send multiple START NOCHECK PROTECT requests to IMS. Each request must be followed by a SYNCPOINT command, or by termination of the transaction.
If the link to a remote region is established, but there are no free sessions available, function shipped EXEC CICS START requests used to schedule remote transactions may be queued in the issuing region. Performance problems can occur if the queue becomes excessively long. This problem is described in topic Intersystem queuing.
For guidance information about controlling intersystem queues, see Intersystem session queue management.
If a remote system is unavailable, either because it is not active or because a connection cannot be established, an attempt to function ship a START request to it normally results in the SYSIDERR condition being returned to the application. This can happen too, when there is a connection to the remote system, but there are no sessions available and you have chosen not to queue the request in the issuing region. However, provided that the remote system is directly connected to this CICS, and that you specify the NOCHECK option on the START command, you can arrange for the request to be queued locally, and forwarded when the required link is in service. You can do this in two ways:
For information about the LOCALQ option, see the CICS Resource Definition Guide.
Your user exit program can decide, on a request-by-request basis, whether to queue locally.
For programming information about the XZIQUE, XISCONA, and XISLCLQ global user exits, see the CICS Customization Guide.
A CICS transaction that is started by a start request can get the user data and other information associated with the request by using the RETRIEVE command.
In accordance with the normal rules for CICS interval control, a start request for a particular transaction that carries both user data and a terminal identifier is queued 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. This has the effect of canceling the queued start request.
Thus, it is possible to design transactions that can handle the data associated with multiple start requests. Typically, a long-running local 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 would 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. If this option is used in a task attached to an APPC device, CICS does not suspend the task, but instead raises the ENDDATA condition if no data is currently available. However, for tasks attached to non-APPC devices, you must make sure that your transaction does not get into a permanent wait state in the absence of further start requests.
If a started transaction issues multiple RETRIEVE commands, or uses the WAIT option of the RETRIEVE command, allow the ROUTABLE option of the transaction definition, in the region in which the START command is issued, to default to ROUTABLE(NO). If the transaction is defined as ROUTABLE(YES), multiple RETRIEVE or RETRIEVE WAIT commands may not work as you expect.
For information about the ROUTABLE option of the START command, see Routing transactions invoked by START commands.
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.
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 locally- or remotely-issued start request is a system, it selects a session available to that system and makes it the principal facility of the started transaction (see Terminology). If no session is available, the request is queued until there is one.
If the link to the system is an APPC link, CICS uses the modename associated with the transaction definition to select a class-of-service for the session.