Using ATI with generic resources

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:

  1. 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.
  2. 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.

  3. 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:

    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:

Notes:
  1. 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.
  2. 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).
  3. 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.
  4. The ATI support described in this section does not apply to ATI to an APPC connection.
  5. 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

  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.
  2. The user runs a transaction, which is routed to an AOR, AOR1. The terminal definition is shipped to AOR1.
  3. 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.
  4. 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.
  5. 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.

Example 2

  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.
  2. The user runs a transaction, which is routed to an AOR, AOR1. The terminal definition is shipped to AOR1.
  3. 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.
  4. 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.
  5. 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.

Related tasks
Planning your CICSplex to use VTAM generic resources
Defining connections in a generic resource environment
Generating VTAM generic resource support
Migrating a TOR to a generic resource
Removing a TOR from a generic resource
Moving a TOR to a different generic resource
Setting up inter-sysplex communications between generic resources
Ending affinities
Using the ISSUE PASS command
Dealing with special cases
Related reference
Prerequisites for VTAM generic resources
Rules checklist
[[ Contents Previous Page | Next Page Index ]]