Sync points
ISC session protocols define RQ*2 requests and their associated responses (DR2 or exception DR2) as sync point requests and responses.
These requests and responses are functionally independent from RQ*1 requests and their associated responses (DR1 and exception DR1), because these latter requests and responses do not cause a sync point. The sync-point responses (DR2) are used between ISC session partners to ensure that both partners' subsystem sync point managers can commit or back out recoverable resources in synchronism.
All messages sent or received on an ISC session are defined as either recoverable or nonrecoverable, depending on the message type. The session response protocols are used to ensure that both partners of an ISC session mutually understand and agree with the recoverability attributes associated with each message. The response protocols used must be consistent with the message type and are enforced by the sending and receiving subsystem sync point managers.
When one session partner commits a message, the other session partner is notified by positive session sync-point responses. When a session partner backs out a message as the result of errors detected during input or output processing, the other session partner is notified either by session termination, by an exception response sent by the receiving subsystem, or by an LUSTATUS-function abort sense code sent by the sending subsystem. Backout results in discarding the currently active message and resetting of the associated ISC data flow control (DFC) and ATTACH states to those of the last sync point.
Because CICS® is a direct-control subsystem, synchronous transactions directly control the ISC session. Therefore, backout during synchronous transaction processing also results in backing out application updates made since the last sync point.
Queued subsystems and asynchronous application output do not provide direct control of the ISC session to the transaction; therefore commit or backout does not affect application updates that are made asynchronously to the message on the ISC session. Because IMS is a queued subsystem, session sync points are separate from application sync points, and always occur outside control of the executing application.
Sync points on IMS input
For any type of input, IMS does not schedule the intended transaction until the complete input message is successfully received. Processing errors and session failure prior to the receipt of the complete input message cause the entire message to be discarded or backed out and have no effect on other recoverable IMS resources, such as databases. However, the input message cannot be canceled by ISC session failures or protocols after the complete message is received, enqueued, and made available for scheduling. Only the current input message is backed out, even when several consecutive input (nonrecoverable) messages are received and enqueued because of a previous input sync point was requested. The definition and relationship of ISC input sync points to the application sync points depend upon whether the internal IMS execution mode for the input is synchronous or asynchronous.
- Response mode transaction
- Conversational mode transaction
- IMS commands
- Test mode input
SEND LAST,
which generates ATTACH with EB, or START/RETRIEVE,
which generates ATTACH SCHEDULER with EB. The following transaction
types are asynchronous: - Nonresponse mode transaction
- Nonconversational mode transaction
- IMS message switch
For IMS, the sync-point response returned to CICS can indicate successful receipt of the message or can indicate the results of IMS processing. For asynchronous input to IMS, the sync-point response returned to CICS indicates only that the input message has been successfully enqueued and that the responsibility for message recovery is assumed by IMS. For synchronous input to IMS, the sync-point response returned to CICS indicates that the transaction has executed successfully and a sync point has been taken, even though transaction execution is independent of the session. IMS reflects this by returning the input sync-point response only after the application-inserted reply message is made available for output as the result of a successful application sync point.
Sync points on IMS output
For output, IMS commits the output message when the requested sync-point response is returned by CICS. This means that the message has been successfully sent and dequeued and the session sync point information has been updated as appropriate. IMS backs out (depending upon the sense code used) the output message when an exception response is returned by CICS. In this case, the message is returned to the message queue for retransmission, and the associated DFC and Attach states are reset to those of the last ISC sync point. Backout on the ISC session does not affect the IMS application program or other recoverable resources, such as database updates. Backout of IMS conversational-mode output, in most cases, causes termination of the IMS conversation and the Conversational Abnormal Termination exit routine to be invoked. Based on the contents of the conversational SPA, user-provided exit logic might schedule another IMS transaction to back out database changes.
CICS sync points
For CICS,
sync points occur under the control of the application program and
can be issued at any time. For synchronous processing, when a sync-point
request is issued by the application program, CICS logs the completion of the logical unit
of work (that is, the resources are committed). In addition, when
the SYNCPOINT command is issued within a CICS application, CICS is responsible for appending the ISC message
that was created as a result of previous processing to the SNA response
request (RQD1 or RQD2) that IMS expects.
However, when a CICS asynchronous
transaction is scheduled as a result of IMS input,
the mirror transaction has already issued a sync point, that causes
the appropriate response to be returned to IMS. Any sync points issued subsequently by the
application have no effect on the ISC session.