Design overview

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:

Consoles are not VTAM resource but they usse a similar mechanism to autoinstall the TCTTE.

Autoinstall of a terminal logon flow

This topic describes the flow of control for a terminal that is to be logged on by autoinstall.

  1. 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:

    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:

    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.

  2. 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.
  3. The DFHZATA program:
    1. Validates the BIND image in the CINIT RU. If the image is not valid, issue message DFHZC6901.
    2. 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.

    3. 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.

    4. On completion of the model search, if any, DFHZATA links to the autoinstall control program (the CICS-supplied default is DFHZATDX).
    5. 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.
    6. 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.
    7. Free the AWE.

Autoinstall of APPC device logon flow

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.

  1. 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.

    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:

    If a match is found showing that this connection already exists then the logon proceeds as for a defined connection.

  2. 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.
  3. The DFHZATA program:
    1. Validates the BIND image passed in the AWE. If the image is not valid, issue message DFHZC6901.
    2. 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.

    3. Issue DFHZCP function(INSTALL) to create the CONNECTION, MODEGROUP and SESSIONs, based on the attributes of the template connection.
    4. 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.

    5. For parallel session with an incoming CINIT, chose the SNASVCMG primary session.
    6. If the install was successful, commit the CONNECTION and queue it for logon processing. The new CONNECTION is queued for OPNDST processing.
    7. 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.

Autoinstall of consoles install flow

  1. The modify command comes into DFHZCNA via a CIB (Command Input Buffer) from MVS when a user types a console command for CICS.
  2. 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.
  3. DFHZACT scans the AWE queue and attached the CATA transaction.
  4. The CATA transaction calls DFHZATA which sees the AWE is fir a console (sometimes called a Console Work Element) and calls DFHZATA2.
  5. DFHZATA2 does the following:
    1. Finds the console models (AICONS is supplied in group DFHTERMC).
    2. 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.
    3. 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.
    4. Calls DFHZCP FUNCTION(INSTALL).
    5. Issues EXEC CICS SYNCPOINT.
    6. Signs on if using preset security of USERID=*EVERY|*FIRST specified in the AI model TYPETERM.
    7. 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.
    8. Call DFHZATT to attach the transaction specified in the MODIFY command (e.g. CEMT).

Sign-on to consoles flow

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:

  1. DFHZCNA receives the modify and
    1. Finds the CCE
    2. Finds that the USERID is different and is already signed on
    3. Creates an AWE for signoff/on
    4. Chains the AWE for DFHZACT.
  2. DFHZACT attaches CATA
  3. CATA calls DFHZATA which calls DFHZATA2 for signoff/on
  4. DFHZATA2 issues preset security sign off for the original USERID followed by sign on for the new USERID
  5. DFHZATA2 then gets a TIOA for the modify command data and calls DFHZATT to attach the transaction as for normal autoinstall for consoles.

Disconnection flow for terminals (LU-initiated)

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.

  1. First the following functions are performed:
  2. Control is then passed to the Close destination program, DFHZCLS, which performs the following functions:
  3. 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.
  4. When the VTAM SHUTD command has completed, VTAM calls the asynchronous send exit, DFHZSAX, which performs the following functions:
  5. 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:
  6. Control is then passed to the Close_Destination program, DFHZCLS. The DFHZCLS program performs the following functions:
  7. 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:
  8. Control is passed to the DFHZNAC program, which performs the following functions:
  9. On the delete request, the DFHZNCA copybook of DFHZNAC checks the value of the system initialization parameter AILDELAY.

    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.

Deletion of autoinstalled APPC devices.

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).

  1. After DFHZCLS, the CLSDST program, issues DFHTCPLR TIDYUP TCSEDDP and TCSE_DELETE_SCHEDULE are set and CATD is initiated with a delay of AILDELAY.
  2. 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.

Deletion of autoinstalled consoles

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.

  1. The delete time is saved in the CCE during install in TCTCE_TIMEOUT_TIME.
  2. DFHCESC runs at certain intervals
  3. DFHCESC checks the CCEs for any console whose delete time has expired
  4. For each expired CCE DFHCESC does the following
    1. Attaches CATD to do the delete
    2. CATD calls DFHZATD as for a terminal

Shipping a TCTTE for transaction routing

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:

Figure 3. Transaction-routing flow for non-APPC devices
 This is a technical drawing showing the transaction-routing flow for non-APPC devices, as described in the text above.

For APPC devices:

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 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 ]]