However, you may be in a situation where you must continue to use unique and
predictable TERMINAL names for your terminals. Your control program must be
able to assign the right TERMINAL name to each terminal, every time the user logs
on. Two possible approaches to this problem are:
v Devise another algorithm to generate predictable TERMINAL names from
NETNAMEs
v Use a table or file to map TERMINAL names to NETNAMEs.
Devising an algorithm avoids the disadvantages of using a table or a file, but it
might be difficult to ensure both uniqueness and predictability. If some of the
information in the NETNAME is not needed by CICS, it can be omitted from the
TERMINAL name. An algorithm is probably most appropriate in this situation.
Using a table has two disadvantages, each of which loses you some of the benefits
of autoinstall: it takes up storage and it must be maintained. You could create a
table in main temporary storage, so that it is placed in extended storage, above
16MB. You could use a VSAM file rather than a table, to avoid the storage problem.
However, this might be slower, because of the I/O associated with a file. The table
or file can contain information such as PRINTER and ALTPRINTER, and you can
add information such as AUTINSTNAME for devices that need particular autoinstall
models. (See “Selecting the autoinstall model” on page 521.)
Considerations for VTAM dynamic alias names: If a CICS region is using
dynamic LU aliases (that is, LUAPFX=xx is specified on the VTAM APPL definition),
selecting a unique TERMINAL name may be more complicated than otherwise. The
following factors should be considered:
v The default programs use the last 4 characters of the NETNAME, which does not
produce a repeatable TERMID for an LU that is assigned a dynamic LU alias.
Consider using the network qualified name in the CINIT or BIND if it is important
that the termid is repeatable for each logon.
v If you use the last 4 characters of the NETNAME, a dynamic LU alias produces a
terminal id of 0001, 0002, and so on. Check that your RDO-defined terminals do
not have such names, and if necessary change your autoinstall control program's
logic. For example, you could use the last character of the NETID concatenated
with the last 3 from the real network name.
v There is some new sample code in DFHZATDX and DFHZATDY that extracts the
network qualified name, referenced as NQNAME, from the CINIT or BIND and
uses the last character of the NETID and the last 3 characters of the real
network name to provide an alternative TERMID.
If this logic fails to create a termid for any reason it drops through to create the
terminal id from the network name as usual. Note this code is enclosed within
comments and is supplied only to illustrate how to extract the required
information from the CINIT and BIND '0E' control vectors
v The sample code is also added in the form of comments to the C, COBOL, and
PL/I versions of DFHZATDX. If you use these, note that:
– The PL/I sample, DFHZPTDX, must be compiled with the PL/I compiler option
LANGLVL(SPROG).
– The COBOL sample, DFHZCTDX, must be compiled with compiler option
TRUNC(OPT).
CICS action on return from the control program
When CICS receives control back from the autoinstall control program, it examines
the return code field. If this is zero, and if the other required information supplied is
Chapter 10. Writing a program to control autoinstall of terminals 523