A new byte TCTE_PRSS has been introduced into the TCTTE to track the stage
reached in the persistent sessions recovery of a session. If for some reason
persistent sessions recovery does not complete, this field can give a useful
indication of the stage reached in recovery when the problem occurred.
- TCTE_NO_PRSS_RECOVERY (X'00')
- The value TCTE_PRSS would normally contain, meaning:
- Persistent sessions are not being used.
- The session was successfully recovered following a persistent sessions
restart.
- The session has been CLSDSTed and restarted since a persistent sessions
restart.
- The session was started after any persistent sessions restart.
If this was a persisting VTAM® session, then TCTE_PRSS will have been
set to this value on completion of recovery notification for non-LU6.2 (see
NAPES84 and NAPES83 routines), or in the session restarted logic of NAPES51
for LU6.2 sessions.
- TCTE_NIB_MATCHED (X'01')
- Placed in TCTE_PRSS by DFHZGRP once a TCTTE has been found which matches
the NIB of a persisting VTAM session. This should be a transient value, as
the OPNDST OPTCD=RESTORE is issued soon after, and should cause TCTE_PRSS
to be updated.
- TCTE_OPNDST_RESTORE_COMPLETED (X'02')
- Placed in TCTE_PRSS once an OPNDST OPTCD=RESTORE has been successfully
issued for a VTAM Session by DFHZGRP. Once this value has been placed in TCTE_PRSS,
the TCTTE should be put onto the activate scan queue to await processing by
DFHZXRC or DFHZXPS.
- TCTE_ZXRC_CLEANUP (X'20')
- Placed in TCTE_PRSS by DFHZXRC when it begins processing a TCTTE. All
TCTE_PRSS values relating to DFHZXRC processing are X'2x'. This value
remains in TCTE_PRSS until the TCTTE is queued to DFHZNAC for the issuing
of message DFHZC0146. If for some reason the TCTTE does not get recovered
and TCTE_PRSS contains this value, then DFHZXRC may be the culprit.
- TCTE_ZXRC_ISSUE_RECOVERY_MSG (X'21')
- DFHZXRC has identified the cleanup and recovery actions required, and
has queued the TCTTE to DFHZNAC for recovery message processing (message DFHZC0146).
If there is any problem with the recovery notification processing in DFHZNCA,
then TCTE_PRSS is likely to contain this value; it may be that the TCTTE has
been taken off the DFHZACT or DFHZNAC queues for an unexpected reason.
- TCTE_ZXPS_CLEANUP (X'30')
- All TCTE_PRSS values beginning (X'3x') indicate that DFHZXPS
is doing its recovery/cleanup processing for this TCTTE. TCTE_PRSS is updated
to this value on entering DFHZXPS for the first time. DFHZXPS should only
be processing LU6.2 sessions.
- TCTE_ZXPS_DEALLOCATE_ABEND (X'31')
- DFHZXPS places this value into TCTE_PRSS prior to calling DFHZGDA for
the first time. It indicates that DFHZXPS has determined that an APPC conversation
was taking place at the time CICS® failed, and that DFHZXPS is calling DFHZGDA
to terminate that conversation. Again, this should be a transient value, as
DFHZGDA will update TCTE_PRSS as it proceeds with its DEALLOCATE(ABEND) processing.
- TCTE_ZXPS_SEND_IN_PROGRESS (X'32')
- DFHZXPS has determined that bidding activity was taking place at the
time CICS failed, and that some kind of SEND is required to complete the bid
flows. If the session hangs with this value in TCTE_PRSS there may have been
some kind of problem with unexpected bid flows taking place.
- TCTE_ZXPS_ISSUE_RECOVERY_MSG (X'33')
- When DFHZXPS has completed recovery and cleanup for the session, it
puts this value into TCTE_PRSS before queueing the TCTTE to DFHZNAC for recovery
message processing.
- TCTE_ZGDA_FMH7_SEND (X'41')
- All TCTE_PRSS values with X'4x' indicate that DFHZGDA is terminating
the APPC conversation which was in progress on the session at the time CICS
failed. This value indicates that DFHZGDA is in the process of issuing a SEND
for the FMH7 which is to terminate the conversation.
- TCTE_ZGDA_FMH7_COMP (X'42')
- DFHZGDA has completed its Deallocate(Abend) processing. This value in
TCTE_PRSS indicates to DFHZXPS that it may continue with any outstanding recovery/cleanup
processing of its own.
- TCTE_ZGA_FMH7_REC (X'43')
- DFHZGDA has determined that CICS was in RECEIVE state at the time CICS
failed, and has issued a RECEIVE for the RU expected from the partner. This
value may appear in sessions which appear to be hanging following a persistent
sessions restart. If the partner never issues the expected SEND, the RECEIVE
will never be executed. Since this RECEIVE is issued under the TCP task, the
RECEIVE will not be subject to any RTIMEOUT.
- TCTE_ZGDA_REC_EOC (X'44')
- Placed in TCTE_PRSS if the first RECEIVE of the DFHZGDA module following
the persistent sessions reveals that the partner is in the middle of sending
a chain of RUs. If TCTE_PRSS contains this value, DFHZGDA has issued a RECEIVE_PURGE
for the session. Again, depending on how quickly the partner sends the expected
data, this session may appear to hang.
- TCTE_ZGDA_SEND_RESP (X'45')
- Placed in TCTE_PRSS if DFHZGDA has to issue a SEND for a response during
Deallocate(Abend) processing.
- TCTE_PRSS_CLSDST_SCHEDULED (X'FF')
- This value is placed in TCTE_PRSS if there is an error, or if in the
course of persistent sessions recovery it is decided to terminate the persisting
session. This may be for a variety of reasons; some of which are:
- An error occurred issuing a SEND or RECEIVE during persistent sessions
recovery.
- RECOVOPT(NONE) or RECOVOPT(UNCONDREL) was specified for the session.
- The only recovery action which DFHZXRC could take was to terminate the
session.
The X'FF' value remains in TCTE_PRSS as an indicator that
the session was terminated during PRSS recovery. Only when the session is
restarted is the value overwritten with X'00'.
[[ Contents Previous Page | Next Page Index ]]