CICS® allows EXEC CICS commands to be issued on APPC conversations
when a backout (rollback) is required but the conversation is not in rollback state (state 13).
When a session is being allocated, the back-end CICS system checks the
incoming bind request for valid combinations of CNOS (change number of sessions)
and parallel-sessions indicators. If CICS finds that parallel-sessions is
specified but CNOS is not, it sends a negative response to the bind request.
CICS allows a sync level-2 conversation to be terminated using the SEND
LAST WAIT or SEND LAST CONFIRM commands. However, doing this is a deviation
from the APPC architecture and should be avoided. Figure 47 illustrates
the problems that can be caused by not syncpointing a sync level-2 conversation.
Figure 47. Losing data integrity on a sync level-2 conversation.
In this example, transaction
AAAA in communicating with transaction BBBB:
- Transaction AAAA issues a CONNECT PROCESS command, specifying SYNCLEVEL(2).
- Transaction AAAA issues a SEND command; the attach header and data is
transmitted, and transaction BBBB is started.
- Transaction BBBB issues a RECEIVE command.
- A serious error occurs in transaction BBBB.
- Transaction BBBB issues an ISSUE ABEND command. The transaction is suspended
pending the receipt of a change direction or end bracket from transaction
AAAA.
- Transaction AAAA issues a SEND LAST WAIT command, with no data. The end
bracket is transmitted to transaction BBBB.
- Transaction BBBB is resumed; the incoming end bracket puts the conversation
into free state.
From this point, the two transactions execute independently.
- Transaction AAAA frees its conversation.
- Transaction AAAA ends; its changes are committed.
- Transaction BBBB issues a SYNCPOINT ROLLBACK command. Its changes are
backed out.
Because transaction AAAA ends the conversation using the SEND LAST WAIT
command, transaction BBBB cannot inform it that an error has occurred. The
ISSUE ABEND command causes the backout-required condition to be raised in
transaction BBBB; so a SYNCPOINT ROLLBACK is needed. Transaction AAAA commits
changes to its resources and data integrity is lost.
The resulting state errors may also lead to the session being unbound.
Where CICS deviates from the APPC architecture, there may be some effect
on transaction programs running on products other than CICS and having conversations
with CICS transactions. The effects can be avoided by using the following
programming conventions (the verbs and return codes referred to here are described
in SNA Transaction Programmer’s Reference Manual for LU Type 6.2):
- When writing a transaction program that will converse with a CICS transaction
program, do not use the verb PREPARE_TO_RECEIVE with the TYPE(CONFIRM) and
LOCKS(LONG) parameters, or with the TYPE(SYNC_LEVEL) and LOCKS(LONG) when
the SYNC_LEVEL is CONFIRM. Instead, use the LOCKS(SHORT) parameter to achieve
the same function. The LOCKS(LONG) parameter provides only a line-flow optimization.
- When writing a transaction program that will converse with a CICS transaction
program, do not depend on the distinction between the return codes PROG_ERROR_PURGING
and PROG_ERROR_NO_TRUNC, and between the return codes SVC_ERROR_PURGING and
SVC_ERROR_NO_TRUNC. Instead, the CICS transaction program must be coded
to send additional error information after it issues the CICS EXEC ISSUE ERROR
in order to describe the reason for sending the error indication.
- When writing a transaction program that will run on CICS, do not depend
on the receipt of the sense data X'08890000' or X'08890100' to
indicate the state of the other end of the conversation when the partner transaction
program sent the error indication. Instead, the partner transaction program
must be coded to send additional error information after it sends the error
indication in order to describe the reason for sending the error indication.
- Because CICS may omit the negative response before an FMH-7 (ALLOCATION_ERROR),
a transaction program in conversation with CICS can receive an ALLOCATION_ERROR after the point where the partner transaction appears to
have been successfully allocated. The transaction program must therefore
be written to handle this possibility.
[[ Contents Previous Page | Next Page Index ]]