Automatic transaction initiation (ATI) is the process whereby a transaction
is started by a request made internally within the CICS® system, rather than by a terminal end-user
entering a transaction name. This can happen when, for example, an application
program issues an EXEC CICS START command, or the trigger level on a transient
data queue is reached. Often the started transaction is associated with a
terminal, which may or may not be owned by the region in which the transaction
runs.
ATI is described in Traditional routing of transactions started by ATI. In particular, Traditional routing of transactions started by ATI describes
how CICS invokes the "terminal not known" global user exits, XICTENF
and XALTENF, to deal with the situation where the terminal is not defined
to the AOR.
When an automatic transaction initiation (ATI) request is issued in an
application-owning region (AOR) for a terminal that is logged on to a TOR,
CICS uses the terminal definition in the AOR to determine the TOR to which
the request should be shipped. If there is no definition of the terminal in
the AOR, you may be able to use the "terminal-not-known" global user
exits (XICTENF and XALTENF) to supply the name of the TOR.
However, if a user logs on to a generic resource (using a generic resource
name), VTAM® may connect his or her terminal to any of the regions in the generic
resource. If the user then logs off and on again, VTAM may connect his terminal
to the same region, or to a different one. In this situation, the terminal
definition in the AOR may not reflect the correct location of the terminal;
and your terminal-not-known exit program has no way of knowing the correct
destination for the ATI request.
CICS solves this problem by using VTAM’s knowledge of where the terminal
is logged on, to ship the ATI request to the correct TOR:
- First, the ATI request is shipped to the TOR specified in the remote terminal
definition (or specified by the terminal-not-known exit)--we shall call
this the "first-choice TOR". If the terminal is logged on to the first-choice
TOR, the ATI request completes as normal.
- If the terminal cannot be located
on the first-choice TOR, the TOR asks VTAM for the applid of the generic resource
member where the terminal is logged on. If the terminal is not logged on to
any applid within the generic resource group, the ATI request fails.
If
the terminal is located on the first-choice TOR but not logged on, the TOR
asks VTAM for the applid of the generic resource member where the terminal
is logged on. If the terminal is not logged on to any applid within the generic
resource group, the ATI request is scheduled on the first-choice TOR. If the
terminal is logged on to a different applid within the generic resource group,
this information is passed to the AOR, and the ATI request is shipped to the
correct TOR.
- If the first-choice TOR is not available (and such an inquiry is possible)
the AOR asks VTAM for the location of the terminal. The inquiry is possible
when all of the following are true:
- The VTAM in the AOR is version 4.2 or later (that is, it supports generic
resources).
- The AOR was started with the VTAM system initialization parameter set
to 'YES'.
- The VTAM generic resource name where
the terminal may be logged on is known to the AOR. Such information is obtained
from the skeleton TCTTE representing the remote terminal. If the first choice
TOR name has been supplied by the user terminal-not-known exit, such an inquiry
is not possible. Note that the inquiry will fail if the terminal is not logged
on to the VTAM generic resource name found in the skeleton TCTTE.
If the AOR is in one network and the TORs in another, the inquiry
fails.
If the inquiry is successful, the ATI request is shipped to
the TOR where the terminal is logged on.
VTAM knows the terminal by its netname, not by its CICS terminal identifier
(TERMID). If there is a terminal definition in the AOR at the time the START
is issued, CICS obtains the netname from that definition. If there is not,
your terminal-not-known exit program should return:
- A netname that VTAM can use to locate the terminal
- The name of a connection to any member of the generic resource that is
likely to be active.
Notes:
- If CICS has no netname for the terminal, the ATI request is shipped to
the first-choice TOR, and the termid is used to locate the terminal. If the
terminal cannot be found on the first-choice TOR, the ATI request fails.
- Because CICS uses the terminal’s netname to find its location in the
generic resource group, the ATI request will still work if, on the second
or subsequent logon, the termid changes (for instance, if the autoinstall
user program does not implement a consistent mapping between netname and termid).
- The ATI support described in this section applies only to terminals that
use the generic name to log on to a generic resource. If a user logs on to
a TOR using the member name, CICS does not attempt to discover from VTAM to
which TOR the terminal is connected.
- The ATI support described in this section does not apply to ATI to an
APPC connection.
- The TORs can use autoinstall or CEDA-defined
terminal definitions.
The AORs must not use CEDA-defined
remote terminal definitions. If CEDA-defined terminals are used, the ATI request
will always be shipped to the first-choice TOR and will not be re-routed to
a different TOR within the same VTAM generic resource group, even though the
terminal may be logged on to another TOR.
Example 1
- A user logs on using the generic resource name CICS, which is the name
of a set of TORs (TOR1 through TOR6). She is connected to TOR1, because it
is the most lightly loaded.
- The user runs a transaction, which is routed to an AOR, AOR1. The terminal
definition is shipped to AOR1.
- The transaction issues an EXEC CICS START request, to start another transaction,
after an interval, against the same terminal. The second transaction, like
the first, is located on AOR1.
- After the first transaction has completed, the user logs off; and logs
on again later to collect the output from the second transaction. When logging
on the second time, again using the generic resource name CICS, the user is
connected to TOR2 because that is now the most lightly loaded.
- The interval specified on the START request expires. However, the terminal
is no longer defined to TOR1. The shipped terminal definition has not yet
been deleted from AOR1 by the timeout delete mechanism.
- Result:
Because the shipped definition of the
user’s terminal still exists on AOR1, AOR1 ships the ATI request to TOR1
(the TOR referenced in the definition). Because the terminal is not logged
on to TOR1, TOR1 queries VTAM and returns the result to AOR1. AOR1 then ships
the request to the correct TOR (TOR2).
Example 2
- A user logs on using the generic resource name CICS, which is the name
of a set of TORs (TOR1 through TOR6). She is connected to TOR1, because it
is the most lightly loaded.
- The user runs a transaction, which is routed to an AOR, AOR1. The terminal
definition is shipped to AOR1.
- The transaction does some asynchronous processing--that is, it starts
a second transaction, which happens to be on another AOR, AOR2. After it has
finished processing, the second transaction is to reinvoke the original transaction
to send a message to the user-terminal at TOR1.
- The user logs off while the application is in process, and logs on again
later to collect the message. When logging on the second time, again using
the generic resource name CICS, the user is connected to TOR2 because that
is now the most lightly loaded.
- The second transaction completes its processing, and issues an EXEC CICS
START command to reinvoke the original transaction, in conjunction with the
original terminal. The START request is shipped to AOR1. However, the terminal
is no longer defined to TOR1, and the shipped terminal definition has been
deleted from AOR1 by the timeout delete mechanism.
- Result:
Because the shipped terminal definition
has been deleted from AOR1, CICS invokes the XICTENF and XALTENF exits. Your
exit program should return:
- The netname of the user’s terminal
- The name of a connection to any member of the generic resource that is
likely to be currently active.
CICS is then able to query VTAM, as described in Example 1, and
ship the request to the correct TOR (TOR2).

[[ Contents Previous Page | Next Page Index ]]