Before a VTAM® device can communicate with CICS®, a VTAM session must be
established between the device and CICS. The sequence of operations is LOGON,
Open Destination (OPNDST), and Start Data Traffic (SDT). CICS can also initiate
the LOGON by using a SIMLOGON.
The session can be requested by:
- Specifying AUTOCONNECT when the terminal is defined to CICS
- A VTAM master terminal command requesting a LOGON to CICS for a given
terminal; for example, V NET,LOGON=CICSA,ID=L3277C1
- An individual terminal operator issuing a LOGON request (LOGON APPLID(CICSA))
- A CICS master terminal command requesting LOGON for a given terminal (CEMT
SET TERMINAL(xxxx) INSERVICE ACQUIRED)
- CICS internally requesting a LOGON; for example, to process an ATI request
- LOGAPPL=CICS in the LU statement.
Consoles are not VTAM resource but they usse a similar mechanism to autoinstall
the TCTTE.
This topic describes the flow of control for a terminal that is to be
logged on by autoinstall.
- When a terminal or single session APPC device attempts
to log on, VTAM drives the logon exit. The CICS logon
exit is DFHZLGX (load module DFHZCY).
In the following circumstances, an LU is a candidate for autoinstall:
- If it is not already defined to CICS (using RDO)
- If neither CICS nor VTAM is quiescing
- If the autoinstall user program (specified by the AIEXIT system initialization
parameter) exists
- If the VTAM RPL is present
- If it is not an LU6.1 session or an LU6.2 parallel session
- If it is an LU6.2 single session terminal and the ISC=YES system initialization
parameter is specified
- If the maximum number of concurrent logon requests (specified by the AIQMAX
system initialization parameter) has not been exceeded.
DFHZLGX searches for the terminal in the terminal control table
(TCT) by comparing the NETNAME passed by VTAM with the NETNAME found in the
NIB descriptor for each installed terminal.
If a match is not found and AUTOINSTALL is enabled (TCTVADEN
is set), CICS verifies that the terminal is eligible for autoinstall. Processing
then consists of:
- Building an autoinstall work element (AWE) by issuing an MVS™ GETMAIN for
subpool 1
- Copying the CINIT RU into the AWE
- Adding the AWE to the end of the AWE chain, which is chained from the
TCT prefix.
If a match is found showing that this autoinstall terminal already
exists, a postponed work element (PWE) is created and the terminal is reinstalled
after deletion of the TCTTE (TCTEDZIP is ON) or if AILDELAY=0. If, however,
AILDELAY¬=0 but TCTEDZIP is not ON (that is, the TCTTE deletion is
pending), the TCTTE is reused after cleanup.
- Later, the work element (AWE) is actioned by DFHZACT attaching transaction
CATA. For every AWE on the AWE chain, the DFHZATA autoinstall program is dispatched,
passing to DFHZATA the AWE’s address.
- The DFHZATA program:
- Validates the BIND image in the CINIT RU. If the image is not valid, issue
message DFHZC6901.
- If VTAM Model Terminal Support (MTS) is being used (ACF/VTAM 3.3 or later), and the name of
a CICS model has been supplied in a X'2F' MTS control vector, DFHZATA
checks that the model exists by using the AIIQ subroutine interface of the
AITM manager (see Autoinstall terminal model manager). If the model does not exist, issue
message DFHZC6936.
DFHZATA compares the BIND image contained in the MTS
model with the BIND image passed in the CINIT RU. If there is a mismatch,
issue message DFHZC6937.
This validated MTS model is the only model
passed to the autoinstall control program.
- In the absence of an MTS model name, DFHZATA browses the autoinstall terminal
model (AITM) table using the AIIQ subroutine interface of the AITM manager.
These models must have been installed, with appropriate TYPETERM definitions,
either at system initialization or by a CEDA INSTALL command.
Compare the
BIND image contained in each model with the BIND image passed in the CINIT
RU, and build a list of suitable models to be passed to the autoinstall control
program.
For autoinstall of an LU to be successful, the following must match:
- CINIT BIND image, taken from the VTAM LOGMODE entry specified for the
LU in the VTAMLST
- Autoinstall terminal model BIND image, built according to the specifications
in the TYPETERM and TERMINAL definitions.
(Both versions of the BIND image should accurately define the characteristics
of the device.) If the model BIND matches the CINIT BIND, the model is added
to the list of candidate entries.
If the list is empty (no matching
models are found), the request is rejected and message DFHZC6987 is written
to the CADL log.
- On completion of the model search, if any, DFHZATA links to the autoinstall
control program (the CICS-supplied default is DFHZATDX).
- Issue DFHZCP_INSTALL to create the TCTTE. DFHZATA uses information from
the model selected by the exit program and the associated TYPETERM entry to
build the TCTTE.
- If the install was successful, commit the TCTTE and queue it for LOGON
processing. The new TCTTE is queued for OPNDST processing, then later the "good
morning" message is written.
- Free the AWE.
This topic describes the flow of control for an APPC parallel session
device (or single session via a BIND) that is to be logged on by autoinstall.
- When an APPC device attempts to logon, VTAM drives the logon exit DFHZLGX
if a CINIT is received, or the SCIP exit DFHZBLX if a BIND is received.
Note that DFHZBLX is a new VTAM exit module that is called by DFHZSCX if an
LU62 BIND has been received.
In the following circumstances, an APPC
LU is a candidate for autoinstall.
- If the connection is not already defined to CICS.
- If the connection is not already installed.
- If the autoinstall user program (specified by the AIEXIT system initialization
parameter) exists and caters for functions 2-4 as well as functions 0-1.
- If the VTAM ACB is open.
- If it is an APPC parallel session connection.
- If it is an APPC single session connection with an incoming BIND (as opposed
to CINIT - which uses terminal autoinstall).
- If ISC=YES is specified in the SIT.
- If the maximum number of concurrent logon requests (specified by AIQMAX)
has not been exceeded.
- If the customer has installed the correct 'template' connection that is
to be 'cloned' (or copied) to create the new connection.
DFHZLGX or DFHZBLX searches for the connection in the terminal control
table (TCT) by comparing the NETNAME passed by VTAM with the NETNAME found
in the NIB descriptor for each installed session.
If a match is found
and AUTOINSTALL is enabled (TCTVADEN is set), CICS verifies that the terminal
is eligible for autoinstall. Processing then consists of:
- Building an autoinstall work element (AWE) by issuing an MVS GETMAIN for
subpool 1.
- Copying the CINIT RU (DFHZLGX) or BIND (DFHZBLX) into the AWE.
- Adding the AWE to the end of the AWE chain, which is chained from the
TCT prefix.
If a match is found showing that this connection already exists then
the logon proceeds as for a defined connection.
- Later, the AWE is actioned by DFHZACT attaching transaction CATA. For
every AWE on the AWE chain, the DFHZATA autoinstall program is dispatched,
passing to DFHZATA the AWE's address.
- The DFHZATA program:
- Validates the BIND image passed in the AWE. If the image is not valid,
issue message DFHZC6901.
- Calls DFHZGAI Function(CREATE_CLONE_BPS) to create a Builder Parameter
Set from which to create the new connection ('clone'). This is done by calling
the customer supplied autoinstall user exit program (which can be based on
DFHZATDY) in which the customer chooses which 'template' connection the new
connection should be copied from.
If at any point DFHZGAI finds a problem
it issues message DFHZC6920 or DFHZC6921 or DFHZC6922 with an exception trace
entry which will explain the reason for failure.
- Issue DFHZCP function(INSTALL) to create the CONNECTION, MODEGROUP and
SESSIONs, based on the attributes of the template connection.
- For parallel sessions with an incoming BIND, chose the SNASVCMG secondary
session and call DFHZGAI (SET_TCTTE_FOR_OPNDST). This mimics code in DFHZBLX
to check the session against the incoming BIND.
If at any point DFHZGAI
finds a problem it issues message DFHZC6923 with an exception trace entry
which explains the reason for failure.
- For parallel session with an incoming CINIT, chose the SNASVCMG primary
session.
- If the install was successful, commit the CONNECTION and queue it for
logon processing. The new CONNECTION is queued for OPNDST processing.
- Free the AWE.
Autoinstall of an APPC Generic Resource connection
If this system is registered as a generic resource and a bind is received
from another generic resource then VTAM exit DFHZBLX will initiate an autoinstall
if there is no generic or member name connection available for use.
An AWE is created with extra parameters such as the generic resource name
and member name of the partner and possibly a suggested template.
Autoinstall then continues as for normal APPC and the extra parameters
are reflected into the TCSE and TCTTE via the BPS.
- The modify command comes into DFHZCNA via a CIB (Command Input Buffer)
from MVS when a user types a console command for CICS.
- DFHZCNA scans the Console Control Elements for a matching console name.
If no CCE is found and autoinstall for consoles is enabled then an Autoinstall
Work Element is created and added to the AWE queue.
- DFHZACT scans the AWE queue and attached the CATA transaction.
- The CATA transaction calls DFHZATA which sees the AWE is fir a console
(sometimes called a Console Work Element) and calls DFHZATA2.
- DFHZATA2 does the following:
- Finds the console models (AICONS is supplied in group DFHTERMC).
- If SIT AICONS(YES) is specified the models are passed to the autoinstall
user-replaceable program which returns the termid. The default autoinstall
user-replaceable program returns the last 4-characters of the consolename.
- If SIT AICONS(AUTO) is specified DFHZGBM is called to get a name in the
console bitmap in the form ^AAA. The autoinstall user-replaceable program
is not called.
- Calls DFHZCP FUNCTION(INSTALL).
- Issues EXEC CICS SYNCPOINT.
- Signs on if using preset security of USERID=*EVERY|*FIRST specified in
the AI model TYPETERM.
- Geta a TIOA to hold the data specified in the command, e.g. if /f jobname,CEMT
I TE was typed at the console then CEMT I TE is put into the TIOA.
- Call DFHZATT to attach the transaction specified in the MODIFY command
(e.g. CEMT).
If a CIB is received with the same console name but with a different USERID
then the autoinstall program DFHZATA2 is called to sign off the original USERID
and sign on to the new USERID as follows:
- DFHZCNA receives the modify and
- Finds the CCE
- Finds that the USERID is different and is already signed on
- Creates an AWE for signoff/on
- Chains the AWE for DFHZACT.
- DFHZACT attaches CATA
- CATA calls DFHZATA which calls DFHZATA2 for signoff/on
- DFHZATA2 issues preset security sign off for the original USERID followed
by sign on for the new USERID
- DFHZATA2 then gets a TIOA for the modify command data and calls DFHZATT
to attach the transaction as for normal autoinstall for consoles.
This topic describes the flow of control when a request is made to disconnect
an autoinstalled terminal (for example, by entering a CESF LOGOFF command),
ultimately causing an EXEC CICS ISSUE LOGOFF command to be issued.
- First the following functions are performed:
- Set on the CLSDST flag in the TCTTE.
- Put the TCTTE on the activate chain for DFHZACT
to dispatch.
- Control is then passed to
the Close destination program, DFHZCLS, which performs
the following functions:
- Set on the SHUTDOWN_IN_PROGRESS flag in the TCTTE.
- Set on the REQUEST_SHUTDOWN flag in the TCTTE.
- The Send asynchronous commands program, DFHZDSA
is then called to send a VTAM SHUTD command to the LU (autoinstalled terminal)
to be disconnected. The DFHZDSA program removes the TCTTE from the activate
chain, pending completion of the SHUTD command.
- When the VTAM SHUTD command has completed, VTAM calls the asynchronous send exit, DFHZSAX, which performs the following functions:
- Set off the REQUEST_SHUTDOWN flag in the TCTTE.
- Set on the SHUTDOWN_SEND flag in the TCTTE.
- Put the TCTTE back on the activate chain for DFHZACT to dispatch.
- VTAM then drives the asynchronous receive exit,
DFHZASX, with
the SHUTC ("shutdown complete") command sent by the LU to be disconnected.
DFHZASX performs the following functions:
- Ensures that the NODE_QUIESCED_BY_CICS, SHUTDOWN_IN_PROGRESS, and CLSDST
flags are still on.
- Puts the TCTTE back on the activate chain for DFHZACT to dispatch.
- Control is then passed to the Close_Destination program, DFHZCLS. The DFHZCLS program performs the following functions:
- Set on the PENDING_DELETE flag in the TCTTE to prevent VTAM exits scheduling
requests for the device.
- Issue UNBIND (CLSDST POST=RESP) for the device.
- The Close destination exit, DFHZCLX, is driven. If the CLSDST request is successful (that is,
there is a positive response from UNBIND), the following functions are performed:
- Set on the SESSION_CLOSED flag in the TCTTE.
- Flag the TCTTE for deletion.
- Enqueue the TCTTE to DFHZNAC.
- Control is passed to the DFHZNAC program, which performs the following
functions:
- Set on the DELETE_REQUIRED flag in the TCTTE.
- Put the TCTTE on the activate chain for DFHZACT to dispatch.
- Issue message DFHZC3462 (session terminated).
- On the delete request, the DFHZNCA copybook of DFHZNAC checks the value
of the system initialization parameter
AILDELAY.
- If AILDELAY is zero, the TCTTE is queued via DFHZACT with the address
of the TCTTE as input. Its function is to perform cleanup operations, the
principal operation being to ask DFHZCQ to delete the TCTTE.
- If AILDELAY is not zero, DFHZNCA initiates CATD using the delay specified
and passes the address of the TCTTE.
Up to three attempts are made to delete the TCTTE. This is because
the reason for the failure may be the existence of a transient condition,
such as the TCTTE being on the DFHZNAC queue to output a message to CSMT.
If the initial delete attempt fails, it is attempted again after one second;
if this fails, another attempt is made after a further 5 seconds. If the
third attempt fails, it is assumed that the failure is a hard failure, which
will not disappear until the device is reconnected; in this case, message
DFHZC6943 is issued, a syncpoint is taken, and the TCTTE delete status is
reset to make the TCTTE reusable.
If the deletion is successful, the
delete is committed, the autoinstall control program is invoked to permit
any specific cleanup operations to take place, and message DFHZC6966 is issued.
If a PWE exists for this TCTTE, the PWE is requeued onto the AWE chain.
Disconnection of an autoinstalled terminal can also be requested by CICS
shutdown, terminal time-out, and terminal errors. In these cases the flow
is slightly different.
This topic describes the flow of control when an APPC sync level 1 device
has its last session released. This can occur as a result of unbind flows
from the partner or a RELEASE command being issued against the connection
in this system.
Only synclevel 1 autoinstalled connections are deleted in this way. They
will have had TCSE_IMPLICIT_DELETE set by the builders from zx_delete_x in
the BPS (set by DFHZGAI).
TCSE_CATLG_NO indicates that the connection is not to be written to the
catalogue (SIT Parameter AIRDELAY=0).
- After DFHZCLS, the CLSDST program, issues DFHTCPLR TIDYUP TCSEDDP and
TCSE_DELETE_SCHEDULE are set and CATD is initiated with a delay of AILDELAY.
- CATD runs DFHZATD which sets TCSE_DELETE_STARTED and calls DFHZCP FUNCTION=DELETE
to delete the sessions, modegroup and connection.
If a SIMLOGON or BIND occur before the delete actually starts (TCSE_DELETE_SCHEDULED)
then the connection delete is aborted and the connection reused.
If a SIMLOGON occurs during the actual delete (TCSE_DELETE_STARTED) then
the delete is vetoed and the connection is reacquired.
If a BIND occurs during the actual delete (TCSE_DELETE_STARTED) then the
delete goes ahead and the PWE that was created is turned into an AWE and the
logon will create a new connection.
If TCSE_DELETE_AT_RESTART is set then DFHZATR will delete the connection
if it has not been used after restart with a delay specified in the SIT AIRDELAY
parameter.
Disconnection flow (APPC devices)
These connections are not deleted at LOGOFF time, so the disconnection
flow is the same as for a defined connection.
Consoles are deleted after a certain period of inactivity. The default
is 60 minutes but this can be overridden in the autoinstall user-replaceable
program.
- The delete time is saved in the CCE during install in TCTCE_TIMEOUT_TIME.
- DFHCESC runs at certain intervals
- DFHCESC checks the CCEs for any console whose delete time has expired
- For each expired CCE DFHCESC does the following
- Attaches CATD to do the delete
- CATD calls DFHZATD as for a terminal
For transaction routing, a terminal can be defined by an entry in the terminal-owning
region (TOR) with the SHIPPABLE=YES attribute. In this case, the terminal
definition is shipped to any application-owning region (AOR) when the terminal
user invokes a transaction owned by (and defined to) that region. Definitions
for advanced program-to-program communication (APPC) devices always have the
SHIPPABLE=YES attribute set.
(The entry in the TOR could have been installed using CEDA INSTALL, the
GRPLIST at system initialization, or autoinstall.)
The first time a transaction is invoked
For non-APPC devices (see Figure 3), the following processing
is performed:
- In the AOR, look for an existing skeleton TCTTE (TCTSK) whose REMOTENAME
is the same as the local name in the TOR. If found, skip the following steps;
otherwise:
- Issue ZC_INQUIRE to the TOR.
- In the TOR:
- Send a builder parameter set (BPS) representing the TCTTE to the AOR.
- Set on the SHIPPED flag (TCTEMROP) in the TCTTE.
- Set on the SHIPPED flag (TCSEMROP) in the TCTSE for the AOR system.
- Rewrite each entry to the catalog.
- In the AOR:
- Use the existing name from the TOR.
- INSTALL the terminal (DFHZATS does the remote install).
- Set on the SHIPPED flag (TCTSKSHI) in the TCTSK.
- Set on the SHIPPED flag (TCSEMROG) in the TCTSE for the TOR system.
- Rewrite each entry to the catalog.
For APPC devices:
- In the AOR, look for an existing skeleton TCTTE (TCTSK) whose REMOTENAME
is the same as the local name in the TOR. If found, skip the following steps;
otherwise:
- INSTALL the terminal (DFHZATS does the remote install).
- Set on the SHIPPED flag (TCTSKSHI) in the TCTSK.
- Set on the SHIPPED flag (TCSEMROG) in the TCTSE for the TOR system.
- Rewrite each entry to the catalog.
When an autoinstalled TCTTE in a TOR is deleted
If this CICS is linked to a Pre CICS/ESA 4.1 system then the following
occurs.
- If the deleted entry is flagged (TCTEMROP or TCSERDLR for APPC devices)
as having been shipped, notify all remote systems that have received shipped
definitions (TCSEMROP) that this terminal is being deleted.
- Determine from the TCTSK in the AOR whether a definition for this terminal
has been shipped (TCTSKSHI). If so, call ZC_DELETE in the AOR.
If this CICS is linked to CICS/ESA 4.1 or above then relevant shipped
terminals are deleted using a separate timing mechanism.
[[ Contents Previous Page | Next Page Index ]]