This topic explains
how autoinstall works with z/OS® Communications
Server. It is intended to help you understand the processing that
takes place when you use autoinstall.
The process of logging on to CICS using autoinstall
(The process
is illustrated in Figure 1 and Figure 2.) CICS® supports the model terminal support (MTS)
function of z/OS Communications
Server. Using MTS, you can define the model name, the printer (PRINTER),
and the alternate printer (ALTPRINTER) for each terminal in a z/OS Communications Server table. CICS captures this information
as part of autoinstall processing at logon, and uses it to create
a TCTTE for the terminal. If you are using MTS, you must use a version
of DFHZATDX that is suitable for use on CICS Transaction Server for z/OS.
See Writing a program to control autoinstall of LUs for
programming information about the user-replaceable autoinstall program.
z/OS Communications Server
receives your request, determines that you want to use CICS, and passes your request to CICS.
CICS extracts the NETNAME
name of your terminal from the logon data. CICS searches the TCT for an entry with the
same NETNAME.
If it finds such an entry, CICS issues
an OPNDST to z/OS Communications
Server to establish a session between CICS and
the terminal. This is the normal CICS logon
process.
If it fails to find a matching entry, CICS checks the system initialization parameters
that were specified in the SIT, or reset by using CEMT, to check whether
it can allow an autoinstall.
If the system initialization parameters allow an autoinstall, CICS checks the terminal data that
is passed by z/OS Communications
Server, to check whether the terminal is eligible for autoinstall.
If the terminal is eligible, CICS examines
the bind image to see whether it carries sufficient information.
If the z/OS Communications
Server bind image data proves sufficient, CICS searches the autoinstall model table (AMT)
in sorted ascending order, and autoinstalls the terminal in one of
the following ways:
If z/OS Communications
Server supplies CICS with a
valid model name, CICS passes
this name to the autoinstall control program. (If the logon
request comes to CICS through z/OS Communications Server, and
if you supply z/OS Communications
Server with names of model terminals, CICS can
obtain the name of the model terminal from the logon data.)
If z/OS Communications
Server does not supply CICS with
a valid model name, CICS searches
the AMT for suitable autoinstall models and passes them to an autoinstall
control program, together with z/OS Communications
Server logon data. If z/OS Communications
Server supplies CICS with an
invalid model name, message DFHZC6936 results.
The autoinstall control program (either the CICS-supplied program
or one written by you) selects one of the models and provides the
rest of the information necessary to complete a TCT entry for
the terminal.
When the autoinstall control program returns control, CICS builds a TCT entry by using
the autoinstall model, the data returned by the autoinstall control
program, and the z/OS Communications
Server logon data for the terminal. CICS then
adds the new entry to the TCT and issues an OPNDST to z/OS Communications Server to establish a session
between CICS and the terminal.
If the TYPETERM definition so specifies, CICS
uses the QUERY function to find out about some of the
features of the terminal. (These features are listed in TYPETERM resources.)
Figure 1. The process of logging
on to CICS using autoinstall.
The autoinstall process itself is shown as a single box.
What happens inside this box is depicted in Figure 2
Figure 2. How CICS autoinstalls a terminal.
The
overall process in which this fits is shown in Figure 1
.
What happens when the user logs off
CICS issues a CLSDST to
ask the z/OS Communications
Server to end the session.
CICS attempts to delete
the TCT entry after a delay specified in the AILDELAY system initialization parameter.
The TCT entry cannot be deleted if there is a lock effective at
the time. For instance, CEMT INQUIRE TERMINAL or an
outstanding ATI request locks the TCT entry.
CICS gives control to the
autoinstall control program in case it has any further processing
to do; for example, to free the TERMINAL name it gave to the terminal.
If the TYPETERM definition of the terminal specifies SIGNOFF(LOGOFF)
and the RACF® segment specifies
timeout, expiry of the timeout period causes the terminal to be logged
off and the user to be signed off. After this automatic logoff, the
delay period commences, leading to deletion of the TCT entry unless
the terminal logs on again before the period ends. For details, see Automatic sign-off, logoff, and TCTTE deletion.
