Handling transaction abends
In addition to the considerations for session and subsystem failure, the design of CICS® recovery transactions must also take into account the actions to be taken in the case of transaction termination as described in the topics that follow.
IMS transaction abend
When an IMS transaction
terminates abnormally, all changes to IMS resources
that were performed by this transaction are backed out by IMS. If the transaction is synchronous (CICS SEND/SYNCPOINT), IMS sends a negative response (exception DR2)
to CICS. This causes the CICS transaction to also terminate
abnormally. As a result of the negative response and subsequent CICS transaction abend, CICS backs out any changes made
to recoverable resources after the previous CICS sync point. An error message is also sent
to CICS; CICS routes this message to the master terminal
destination CSMT. The exception occurs when MFS output formats do
not exist in the format library or incur an I/O error. In this case, IMS has already sent a positive sync-point
response and must indicate the MFS error to CICS by using an ATTACH SYSMSG
.
If
the transaction is asynchronous (CICS START
or SEND
LAST
), IMS sends an
error message to CICS; CICS routes this message to its
master terminal destination. The error message is preceded by either
a SYSMSG or an ERP header, depending upon the type of error that occurs.
If the error occurs before IMS sends
a sync-point response to input, an exception response and ERP are
used; if after the sync-point response, ATTACH SYSMSG
is
used.
CICS transaction abend
If
a transaction is initiated by a CICS subsystem
acting as a front end for IMS,
and that CICS transaction terminates
abnormally before reaching sync point, any processing performed is
handled in accordance with the specification on the DEFINE
TRANSACTION IN-DOUBT
parameter (or DFHPCT DTB=
parameter).
If an asynchronous transaction is initiated by an IMS front end and the CICS transaction abends upon receipt of the transaction, IMS is not notified. This is because the receipt of the message causes the CICS mirror transaction to return an immediate DR2 to the asynchronous input and to schedule a transaction to process it. If this scheduled transaction fails, the ISC link to IMS is no longer active and no notification is possible. CICS does, however, notify the CICS destination CSMT of the transaction failure.
During synchronous processing,
if CICS is the secondary half
session, the ALLOCATE
command has been successfully
issued, and no message is available to be sent to IMS (due, for example, to DTB causing backout), CICS automatically deallocates
the session by sending LUSTATUS BB/EB
to IMS.
If the synchronous transaction terminates
abnormally any time after it has sent a message to IMS using the SEND/SYNCPOINT
command,
and that message has been enqueued on an IMS input
queue, IMS processes it. When IMS attempts to send an output message
to CICS, that message receives
a negative response from CICS.
As a result, the message can remain on the IMS output queue until it can be re-sent or until
it is dequeued by the IMS master
terminal operator.