Application programming for CICS transaction routing

In general, if you are writing a transaction that may be used in a transaction routing environment, you can design and code it just as you would for a single CICS® system. There are, however, a number of restrictions that you must be aware of, and these are described in this section. The same considerations apply if you are migrating an existing transaction to the transaction routing environment.

The program can be written in PL/I, COBOL, C, or assembler language. This choice might, of course, be restricted by the terminal or session type: basic APPC conversations, for example, must be written in C or assembler language.

Application programming restrictions and considerations

There are a number of restrictions and considerations when you write application programs for transaction routing.

Basic mapping support (BMS)

Any BMS maps or partition sets that your program uses must reside in the same CICS system as the program.

In a BMS routing application, a route request that specifies an operator or an operator class directs output only to the operators signed on at terminals that are owned by the system in which the transaction is executing.

The mapset name specified in the most recent SEND MAP command is saved in the TCTTE. For a routed transaction, this means that the mapset name is saved in the surrogate TCTTE and, when the routed transaction terminates, the most recently used mapset name is passed in a DETACH sequence from the AOR to the TOR.

Similarly, when a routed transaction is initiated, the most recently used mapset name is passed in an ATTACH sequence from the TOR to the AOR.

The map name is supported in the same way as the mapset name. However, some old CICS products (no longer supported) have no knowledge of map names being passed in ATTACH and DETACH sequences. When sending an ATTACH sequence, CICS Transaction Server for z/OS® systems set the map name to null values in the “real” TCTTE, in case the AOR is unable to return a map name in the DETACH sequence. In other words, the TCTTE in the TOR contains a null value for the saved map name, rather than a potentially incorrect name.

The names of mapsets and maps saved in the TCTTE can be both queried and updated by the MAPNAME and MAPSETNAME options of the INQUIRE TERMINAL and SET TERMINAL commands.

Pseudoconversational transactions

A routed transaction requires the use of an interregion or intersystem (APPC) session for as long as it is running. For this reason, long-running conversational transactions are best duplicated in the two systems, or alternatively designed as pseudoconversational transactions.

Take care in the naming and definition of the individual transactions that make up a pseudoconversational transaction, because a TRANSID specified in a CICS RETURN command is returned to the terminal-owning region, where it may be a local transaction.

There is, however, no reason why a pseudoconversational transaction cannot be made up of both local and remote transactions.

The terminal

The terminal with which your transaction runs is represented by a terminal control table terminal entry (TCTTE). This TCTTE, called a surrogate TCTTE , is in many respects a copy of the “real” terminal's TCTTE in the terminal-owning region. CICS releases the surrogate TCTTE when the transaction terminates. Subsequent tasks run using new copies of the real terminal's TCTTE.

If your program needs to discover terminal-related information, consider the following points:
  • Your program should not test fields in the TCTTE directly: it should test instead the equivalent fields in the EXEC interface block (EIB).
  • If the new task is started by ATI, the contents of certain terminal-related fields in the EIB are unpredictable. EIBAID, which contains the attention identifier, is always set to zeros at the start of a session.