Design overview

CICS® support of persistent sessions includes the support of all LU-LU sessions except LU0 pipeline and LU6.1 sessions. CICS determines for how long the sessions should be retained from the PSDINT system initialization parameter. (This is a user-defined time interval.) If a failed CICS is restarted within this time, it can use the retained sessions immediately--there is no need for network flows to re-bind them.

This interval can be changed using the CEMT SET VTAM® command, or the EXEC CICS SET VTAM command, but the changed interval is not stored in the CICS global catalog, and therefore is not restored on an emergency restart.

If CICS is terminated through CEMT PERFORM SHUTDOWN IMMEDIATE, or if CICS fails, VTAM holds CICS’ sessions in "recovery pending" state.

During emergency restart, CICS restores those sessions pending recovery from the CICS global catalog and the CICS system log to an "in session" state. This happens when CICS opens its ACB.

Subsequent processing is LU dependent: cleanup and recovery for non-LU6 persistent sessions is similar to that for non-LU6 backup sessions under XRF. Cleanup and recovery for LU6.2 persistent sessions maintains the bound session when possible but there may be cases where it is necessary to unbind and re-bind the sessions, for example, where CICS fails during a session resynchronization.

The end user of a terminal sees different symptoms of a CICS failure following a restart, depending on whether VTAM persistent sessions, or XRF, are in use:

Note:
SNPS support does not retain LU-LU sessions after VTAM, MVS™, or CEC failure. Nor are sessions retained after the following commands:

MNPS differs from SNPS in that MNPS support retains LU-LU sessions after a VTAM and MVS failure. The sessions are also retained after:

Persistent Sessions Restart flow

The following describes the flow of control for:

  1. The enabling of persistence
  2. The sessions that persist at start up time
  3. The sessions that persist during dynamic open.

Enabling of persistence

Summary
  1. VTAM ACB opened with PARM=PERSIST=YES
  2. VTAM levels checked.
  3. VTAM SETLOGON OPTCD=PERSIST or NPERSIST
More detail

Persistence is enabled by:

  1. The VTAM ACB is opened with PARM=PERSIST=YES - specified in DFHTCTPX.
  2. DFHZSLS calls DFHZGSL to issue SETLOGON OPTCD=PERSIST/NPERSIST.

    DFHZSLS copies 8 bytes of VTAM information into the TCT prefix. These bytes contain details of the VTAM level and the functions which it supports. Previous releases of CICS only copy 4 bytes of VTAM data.

    The use of persistent sessions is dependent upon the level of VTAM present being at least V3R4.1. This level of VTAM returns more function bit data to CICS than previous versions and supports the use of persistent sessions. Checks are made by CICS of the current VTAM level and the VTAM level against which the TCT was generated. If either level is not high enough, parameters relating to the use of persistent sessions are not used when macros are called.

Sessions that persist at start up time

Summary
  1. Task CGRP runs DFHZCGRP
  2. DFHZCGRP calls DFHZGRP
  3. DFHZGRP issues VTAM INQUIRE
  4. DFHZGRP either:
  5. DFHZGRP queues restored sessions for further processing.
  6. DFHZGRP issues RECEIVE_ANYs.
  7. DFHZGRP does some CNOS work.
  8. DFHZGRP does some URD work.
  9. Queued sessions get restored.
More detail

Sessions that persist at startup time are processed by:

  1. Attach task CGRP - program DFHZCGRP in DFHSII1 after TCRP is attached.
  2. DFHZCGRP calls DFHZGRP with a START_TYPE of:
  3. DFHZGRP issues VTAM INQUIREs in 'chunks', that is VTAM is passed an area whose size is defined in the TCT Prefix.

    The area is filled with NIBS by VTAM. DFHZGRP scans the NIBS and decides whether to UNBIND or OPNDST each session.

    For COLD, WARM and EMER_XRF all sessions are unbound.

    For EMER some sessions are unbound and some restored depending on the circumstances.

  4. Restored sessions are queued to DFHZACT for further processing by DFHZXRC or DFHZXPS.
  5. RECEIVE_ANY Initialization done.
  6. CNOS records are processed by making calls to DFHZGPC.
  7. URDS are reset to AWAITING RE_SYNCHRONIZATION for EMER only.
  8. DFHZACT calls DFHZXRC or DFHZXPS for each session queued by DFHZGRP.
Task and module Flow diagram
-> indicates an ATTACH
 
  TASK
                           TCRP
   1     TCP      III      CSSY           CGRP
         ---      ---      ----           ----
  .
  .
  SII1->ZCSTP
         ZDSP
         .ZSLS
         . ZGSL
         Spin on
         TCTV_RA_DONE
         .
  SII1---------->SII1 --->TCRP
                 SII1----------------->   ZCGRP
         .       .        . install       .ZGRP
         .       .        . TCTTEs        .  INQUIRE on
         .       .        . etc           .  persistent sessions
         .       .        .               .  wait on TCTVCECB (EMER)
         .       .        . Post TCTVCECB
         .       .        task end        .
         .       .                        .  process persistent
         .       .                        .  sessions
         .       .                        .  RECEIVE_ANY processing
         ZDSP continues <------------------- set TCTV_RA_DONE
                 .                           post TCTV_ZGRP_FIN_ECB
                 .                        task end
                 . Wait on
                 . TCTV_ZGRP_FIN_ECB
                 SIJ1
                 . SETLOGON START
                 . Start CXRE task
                 . Control is Given to CICS
         ZACT
         . ZXRC
         . ZXPS
Task and module flow - more detail.
  1. Startup runs as normal until DFHSII1 has started the TCP (CSTP) task and DFHZDSP runs.
  2. DFHZDSP calls DFHZSLS. DFHZSLS does NOT issue RECEIVE OPTCD=ANY. It returns to DFHZDSP which ‘spins" until TCTV_RA_DONE is set by DFHZGRP when the RECEIVE_ANYs have been successfully issued.
  3. DFHSII1 attaches the III task which continues to run code in DFHSII1.
  4. DFHSII1 (III) attaches and calls DFHTCRP as a system task then attaches task CGRP, which runs program DFHZCGRP which calls ZGRP.
  5. DFHZGRP calls DFHZGUB if there are any sessions to unbind.
  6. DFHZGRP queues any sessions to be restored to DFHZACT.
  7. DFHZGRP sets TCTV_RA_DONE after issuing RECEIVE_ANYs to allow DFHZDSP to continue.
  8. DFHZGRP posts TCTV_ZGRP_FIN_ECB.
  9. When DFHZGRP finishes, control is returned to code in DFHZCGRP.

    DFHZCGRP checks the RESPONSE and REASON code. It sets TCTV_ZGRP_FAILED off if RESPONSE(OK) or RESPONSE(EXCEPTION) with REASON(ACB_CLOSED|INQUIRE_FAILED). Otherwise it sets TCTV_ZGRP_FAILED on.

  10. DFHSII1 waits on TCTV_ZGRP_FIN_ECB and checks TCTV_ZGRP_FAILED set by DFHSII1.

    If TCTV_ZGRP_FAILED is off then DFHSII1 continues Otherwise it sets INITDERR which causes CICS to terminate when the other tasks have finished.

  11. Just before CONTROL IS GIVEN to CICS, DFHSIJ1 attaches the CXRE task to run DFHZXRE0 which does some additional PRSS processing.
  12. DFHZXRC or DFHZXPS are then called to process any TCTTEs queued to DFHZACT.
  13. DFHZXRC is called by DFHZACT to process non-APPC sessions which have not been unbound by DFHZGRP. It takes one of the following actions depending on the state of the session, the terminal type, and how the TYPETERM for the session has been defined to CICS.

    For those devices for which the cleanup action is not to unbind, the TCTTE is queued to DFHZNAC and message DFHZC0146 is issued for the session.

    As part of the processing for message DFHZC0146, any recovery notification requested for the session is initiated:

  14. DFHZXPS is called by DFHZACT to process APPC sessions.

    DFHZXPS takes one of the following courses of action depending on the setting of TCTE_PRSS on entry.

Sessions that persist at Dynamic Open

If VTAM fails but CICS stays up SNPS sessions do not exist. For MNPS they do persist. When VTAM crashes, CICS does not delete the autoinstalled resources and resets all the terminal and connection sessions to unopened state.

Summary
  1. CEMT SET VTAM OPEN
  2. DFHEIQVT calls DFHZOPA
  3. DFHZOPA calls DFHZSLS
  4. DFHZSLS call DFHZGSL
  5. DFHZGSL issues SETLOGON PERSIST or NPERSIST
  6. DFHZOPA calls DFHZGRP
  7. DFHZGRP issues INQUIRE PERSESS
  8. DFHZGRP terminates session via DFHZGUB issuing CLSDST/TERMSESS. However, if MNPS is in use the sessions are OPNDST RESTOREd instead.
  9. DFHZGRP issues RECEIVE_ANYs
  10. DFHZGRP deletes CNOS catalogue records
  11. DFHZOPA issues SETLOGON START
More detail

Sessions that persist after the ACB has been opened using CEMT SET VTAM OPEN or EXEC CICS SET VTAM OPEN are processed by:

  1. CICS is running with the VTAM ACB closed.

    CEMT SET VTAM OPEN or EXEC CICS SET VTAM OPEN is issued.

  2. DFHEIQVT calls DFHZOPA to open the ACB.
  3. DFHZOPA calls DFHZSLS.
  4. DFHZSLS calls DFHZGSL.
  5. DFHZGSL issues VTAM macro calls dependent upon the VTAM level and PSDINT value.
  6. DFHZOPA then calls DFHZGRP with startup type of DYNOPEN.
  7. DFHZGRP issues INQUIRE PERSESS with a storage area that will take up to about 400 sessions - INQUIRE PERSESS is reissued until all the NIBs have been obtained from VTAM.
  8. DFHZGRP calls DFHZGUB if there are any sessions to unbind. For MNPS DFHZGRP instead issues OPNDST RESTORE for each session that persists.
  9. DFHZGRP issues RECEIVE_ANYs.
  10. DFHZGRP calls DFHZGCC to delete CNOS records.
  11. If ZGRP returns RESPONSE(OK) or RESPONSE(EXCEPTION) with REASON(ACB_CLOSED|INQUIRE_FAILED) then DFHZOPA issues SETLOGON OPTCD=START. Otherwise it causes DFHZSHU to be run to close the VTAM ACB and then returns to DFHEIQVT.

TCB Concurrency

Summary

If SUBTSKS = 1 Specified in SIT

More detail

During startup DFHZGRP is attached as a task and runs at the same time as other startup tasks such as DFHTCRP and DFHRCRP. However, DFHZGRP also switches to use the CONCURRENT TCB if there are enough NIBS to process during EMER start.

This allows DFHZGRP to issue INQUIRE OPTCD=PERSESS as many times as is necessary, concurrently with the TCTTEs being restored by DFHTCRP.

When DFHZGRP finishes INQUIREing it waits for DFHTCRP to finish before matching each persisting NIB with the restored TCTTEs.

Each NIBLIST is then OPNDST OPTCD=RESTOREd and while this is running asynchronously DFHZGUB is called to run under the concurrent TCB if there are enough NIBs to be unbound in the NIBLIST.

Start of change

Persistent Signon under Persistent Sessions

  1. After the persistent session has been recovered, the TCTTE is marked to indicate that the signon will persist.
  2. The RECOVNOTIFY message or transaction is processed.
    Note:
    Because RECOVNOTIFY is processed before persistent signon is recovered, only the first transaction specified in the RMTRAN system initialization parameter will be processed; the second transaction specified cannot be processed because security has not yet been restored yet.
  3. The user presses an Attention IDentifier (AID) key.
  4. CICS runs the CPSS transaction to recover the signon.
End of change [[ Contents Previous Page | Next Page Index ]]