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:
- SET VTAM FORCECLOSE
- SET VTAM IMMCLOSE
- SET VTAM CLOSED
- PERFORM SHUTDOWN
- VARY INACT ID=applid
MNPS differs from SNPS in that MNPS support retains LU-LU sessions
after a VTAM and MVS failure. The sessions are also retained after:
The following describes the flow of control for:
- The enabling of persistence
- The sessions that persist at start up time
- The sessions that persist during dynamic open.
Enabling of persistence
Summary
- VTAM ACB opened with PARM=PERSIST=YES
- VTAM levels checked.
- VTAM SETLOGON OPTCD=PERSIST or NPERSIST
More detail
Persistence is enabled by:
- The VTAM ACB is opened with PARM=PERSIST=YES - specified in DFHTCTPX.
- 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
- Task CGRP runs DFHZCGRP
- DFHZCGRP calls DFHZGRP
- DFHZGRP issues VTAM INQUIRE
- DFHZGRP either:
- terminates session via DFHZGUB issuing CLSDST/TERMSESS or
- restores the session with OPNDST TYPE=RESTORE
- DFHZGRP queues restored sessions for further processing.
- DFHZGRP issues RECEIVE_ANYs.
- DFHZGRP does some CNOS work.
- DFHZGRP does some URD work.
- Queued sessions get restored.
More detail
Sessions that persist at startup time are processed by:
- Attach task CGRP - program DFHZCGRP in DFHSII1 after TCRP is attached.
- DFHZCGRP calls DFHZGRP with a START_TYPE of:
- 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.
- Restored sessions are queued to DFHZACT for further processing by DFHZXRC
or DFHZXPS.
- RECEIVE_ANY Initialization done.
- CNOS records are processed by making calls to DFHZGPC.
- URDS are reset to AWAITING RE_SYNCHRONIZATION for EMER only.
- 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.
- Startup runs as normal until DFHSII1 has started the TCP (CSTP) task and
DFHZDSP runs.
- DFHZDSP calls DFHZSLS.
- If VTAM is at least V3R4.1, DFHZSLS calls DFHZGSL to issue SETLOGON OPTCD=PERSIST
if the SIT PSDINT value is a valid non 0 value.
- If the VTAM level is V3R4.0 or PSDINT is 0 or defaulted with higher levels
of VTAM, DFHZSLS calls DFHZGSL to issue SETLOGON OPTCD=NPERSIST.
- If the VTAM level is lower than V3R4.0, the SETLOGON OPTCD call is not
made since PERSIST and NPERSIST are not supported for these VTAM releases.
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.
- DFHSII1 attaches the III task which continues to run code in DFHSII1.
- DFHSII1 (III) attaches and calls DFHTCRP as a system task then attaches
task CGRP, which runs program DFHZCGRP which calls ZGRP.
- DFHZGRP calls DFHZGUB if there are any sessions to unbind.
- DFHZGRP queues any sessions to be restored to DFHZACT.
- DFHZGRP sets TCTV_RA_DONE after issuing RECEIVE_ANYs to allow DFHZDSP
to continue.
- DFHZGRP posts TCTV_ZGRP_FIN_ECB.
- 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.
- 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.
- Just before CONTROL IS GIVEN to CICS, DFHSIJ1 attaches the CXRE task to
run DFHZXRE0 which does some additional PRSS processing.
- DFHZXRC or DFHZXPS are then called to process any TCTTEs queued to DFHZACT.
- 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.
- Send END_BRACKET
- Send CLEAR (followed by START_DATA_TRAFFIC for SNA devices which support
it)
- Unbind.
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:
- If the requested recovery notification is MESSAGE, DFHZNCA sends a BMS
map to the terminal.
- If the requested recovery notification is TRANSACTION, DFHZNCA initiates
the requested transaction.
- 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.
- Examine the data pointed to by TCTV_PRSS_CV29_PTR to determine the state
of the session at system failure.
- If a task is attached call DFHZGDA to issue DEALLOCATE,ABEND for the task
still running on the partner.
- If no task is attached but there is further recovery to be done e.g. bid
recovery, outstanding responses, set the TCTTE to a state which allows this
further recovery to proceed. If the existing mechanism will carry out the
recovery without further intervention by DFHZXPS then remove the TCTTE from
the DFHZACT queue, otherwise requeue the TCTTE to DFHZACT and DFHZXPS will
be recalled at a later stage to finish recovery processing.
- If no task is attached and there is no further recovery to be done, remove
the TCTTE from the DFHZACT queue as recovery is now complete.
- Recall DFHZGDA to continue with DEALLOCATE,ABEND or REJECT_ATTACH processing.
- Requeue the TCTTE to DFHZACT if a SEND (for example of an outstanding
response) which was set in motion by an earlier instance of DFHZXPS is still
in progress.
- CLSDST the session if an error has occurred during the recovery process.
- Carry out further recovery as described above, if required, following
successful completion of DEALLOCATE,ABEND processing.
- Remove the TCTTE from the DFHZACT queue when all recovery has completed.
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
- CEMT SET VTAM OPEN
- DFHEIQVT calls DFHZOPA
- DFHZOPA calls DFHZSLS
- DFHZSLS call DFHZGSL
- DFHZGSL issues SETLOGON PERSIST or NPERSIST
- DFHZOPA calls DFHZGRP
- DFHZGRP issues INQUIRE PERSESS
- DFHZGRP terminates session via DFHZGUB issuing CLSDST/TERMSESS. However,
if MNPS is in use the sessions are OPNDST RESTOREd instead.
- DFHZGRP issues RECEIVE_ANYs
- DFHZGRP deletes CNOS catalogue records
- 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:
- CICS is running with the VTAM ACB closed.
CEMT SET VTAM OPEN or EXEC
CICS SET VTAM OPEN is issued.
- DFHEIQVT calls DFHZOPA to open the ACB.
- DFHZOPA calls DFHZSLS.
- DFHZSLS calls DFHZGSL.
- DFHZGSL issues VTAM macro calls dependent upon the VTAM level and PSDINT
value.
- If VTAM is at least V3R4.1, DFHZGSL issues SETLOGON OPTCD=PERSIST if the
SIT PSDINT value is a valid non 0 value.
- If the VTAM level is V3R4.0 or PSDINT is 0 or defaulted with higher levels
of VTAM, DFHZGSL issues SETLOGON OPTCD=NPERSIST.
- If the VTAM level is lower than V3R4.0, the SETLOGON OPTCD call is not
made since PERSIST and NPERSIST are not supported for these VTAM releases.
- DFHZOPA then calls DFHZGRP with startup type of DYNOPEN.
- 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.
- DFHZGRP calls DFHZGUB if there are any sessions to unbind. For MNPS DFHZGRP
instead issues OPNDST RESTORE for each session that persists.
- DFHZGRP issues RECEIVE_ANYs.
- DFHZGRP calls DFHZGCC to delete CNOS records.
- 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
- DFHZGRP switches to concurrent TCB if enough NIBS to process.
- INQUIRE PERSESS work done concurrently with TCRP ZC INSTALL.
- DFHZGUB switches to concurrent TCB if enough NIBS to process. (EMER only).
- OPNDST RESTORE and CLSDST/TERMSESS done concurrently.
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.
Persistent Signon under Persistent Sessions
- After the persistent session has been recovered, the TCTTE is marked to
indicate that the signon will persist.
- 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.
- The user presses an Attention IDentifier (AID) key.
- CICS runs the CPSS transaction to recover the signon.
[[ Contents Previous Page | Next Page Index ]]