Installing shipped terminals and connections

In releases of CICS® before 4.1, the terminal identifiers (TERMIDs) of shippable terminals had to be unique in the transaction routing network. That is, you could not ship a terminal definition to an AOR on which a remote terminal of the same name was already installed. From CICS/ESA 4.1 onwards, this restriction does not apply. Because your autoinstall control program is invoked for shipped terminals and connections, you can use it to reset the TERMINAL (or CONNECTION) attribute of a shipped definition to an alias, thereby avoiding conflicts with names of remote terminals and connections already installed in the AOR. There is no need to reset the REMOTENAME attribute, which remains set to the name by which the terminal is known in the TOR; and autoinstall model names are not applicable to shipped definitions.

Note:
If the name of a shipped definition clashes with the name of a local terminal or connection installed in the AOR, the install is rejected, and the autoinstall control program is not invoked.

For more information about using aliases on remote definitions, see the CICS Intercommunication Guide.

Note:
The autoinstall control program is invoked for all shipped terminals and connections, including shipped definitions of the virtual terminals used by CICS Clients.

CICS-generated aliases

The autoinstall control program is invoked once for each shipped terminal or connection definition to be installed.

If CICS detects that the name on a shipped definition clashes with the name of a remote terminal or connection already installed in the AOR, it generates an alias TERMID and passes it to the control program in field SELECTED_SHIPPED_TERMID of the communications area.

If CICS detects that there is no clash of names, it passes in SELECTED_SHIPPED_TERMID the name by which the terminal or connection is known in the TOR--that is, the value of the TERMINAL or CONNECTION attribute on the shipped definition.

Your control program can accept the passed TERMID, change it, or reject the installation of the shipped definition.

CICS-generated aliases consist of a 1-character prefix and a 3-character suffix. The prefix is always '{'. The suffix can have the values 'AAA' through '999'. That is, each character in the suffix can have the value 'A' through 'Z' or '0' through '9'. The first suffix generated by CICS has the value 'AAA'. This is followed by 'AAB', 'AAC', ... 'AAZ', 'AA0', 'AA1', and so on, up to '999'.

Each time that it needs to create an alias, CICS generates a 3-character suffix that it has not recorded as being in use. If your autoinstall control program overrides a CICS-generated TERMID, CICS does not record the suffix as being in use, and supplies the same suffix for the next alias.

Resetting the terminal identifier

You need to think about the algorithm by which your control program allocates alias TERMIDs.

You must consider the consequences of a definition being deleted by the CICS timeout delete mechanism, and subsequently being re-shipped and re-installed. You must decide whether your autoinstall program should allocate the same TERMID as before (which implies a file mapping the name by which the terminal is known in the TOR to the alias allocated by the AOR), or whether allocation of a different TERMID is acceptable--in which case you could use the default aliases generated by CICS. This decision may depend on several factors. For example:

Example

Assume that you have two terminal-owning regions, TORA and TORB, and that they use the same set of terminal identifiers, T001 through T500. TORA and TORB route transactions to the same application-owning region, AOR1. To prevent naming conflicts when terminals are shipped to AOR1, your control program in AOR1 could:

This solution allows two TORs using the same set of TERMIDs to access the same AOR. However, even though the aliases created in the AOR are mapped consistently to TERMIDs in the TOR, the solution does not guarantee that data mismatch problems cannot occur if terminals are re-shipped. This is because it relies on TERMIDs being allocated consistently in the TOR--that is, on specific TERMIDs always being assigned to the same physical devices.

Note:
Your control program could use the correlation identifier contained in each terminal and connection definition to check whether a definition has been re-installed in the TOR--see the description of the INSTALL_SHIPPED_CORRID_PTR parameter in The communications area at INSTALL for shipped terminals.

A better solution might be to map the terminal alias in the AOR to the netname of the terminal. This would at least guarantee that a specific alias always relates to the same physical device. But it would still require TERMIDs for which aliases are not created to be consistently allocated in the TOR.

Related tasks
Rewriting user-replaceable programs
Assembling and link-editing user-replaceable programs
Writing a program to control autoinstall of terminals
Writing a program to control autoinstall of consoles
Writing a program to control autoinstall of APPC connectionsWriting a program to control autoinstall of virtual terminals
Related reference
The autoinstall control program at INSTALL
The autoinstall control program at DELETE
Default actions of the sample programs
[[ Contents Previous Page | Next Page Index ]]