CA Datacom/DB SQL Preprocessors › SQL Plan Options Special Topics › CICS Unit of Recovery End

CICS Unit of Recovery End

If your plan is for a CICS application, CA Datacom CICS Services issues a CICS SYNCPOINT and issues either a COMIT or ROLBK to end the unit of recovery:

• At the end of each asynchronous CICS task, or
• At the end of each synchronous CICS task (that is , a task associated with a terminal) if:
  • A task abnormally terminates, or
  • A task returns control to CICS, or
  • ISOLEVEL=C and at least one cursor is left open, or
  • ISOLEVEL=C and INSERT, UPDATE, or DELETE statements have been executed.

CA Datacom CICS Services does not issue a CICS SYNCPOINT and does not issue a COMIT or ROLBK to end the unit of recovery when:

• A synchronous CICS task terminates successfully, and
• The transaction ID is specified in the RETURN statement, and either:
  • ISOLEVEL=U, or
  • ISOLEVEL=C, no cursor is left open, and no INSERT, UPDATE, or DELETE statements have been executed.

However, the SQL Manager automatically ends a unit of recovery after each SQL statement if there are:

• No open cursors,
• No table-level locks, and
• No primary or secondary exclusive control is being held.

For example, if ISOLEVEL=U and you have only SELECT INTO statements or no open cursors, you need not execute a COMMIT WORK statement at CICS transaction end because there is no current unit of recovery active.

The only case where the unit of recovery is left active when the synchronous CICS task ends successfully is therefore when ISOLEVEL=U and a cursor is left open.

Note: If you code ISOLEVEL=U, you are responsible for ending the current unit of recovery as follows:

• We recommend ending the current unit of recovery by closing all open cursors. Or, if your user application logic does not support this method,
• Issue a CICS SYNCPOINT (see the CA Datacom CICS Services User Guide). Or, if your user application logic does not support this method,
• Issue an appropriate SQL statement (COMMIT WORK or ROLLBACK WORK). Or, if your user application logic does not support this method, as a last option,
• Issue an appropriate CA Datacom/DB record-at-a-time command (LOGCP, LOGCR, LOGTB, COMIT, or ROLBK).

  Be aware that if a CA Datacom/DB log command is issued in a situation where a single transaction talks to multiple Multi-User Facilities, unpredictable results can occur. This is why using other methods of ending the current unit of recovery are recommended before this last option.

When you do not do one of the previously given actions and the current unit of recovery remains active, it allows a browse application to keep cursors open across CICS synchronous transactions. Be aware, however, that if that was not what you intended, the plan stays locked in share mode, and memory is held in the Multi-User Facility until the unit of recovery is ended.

For example, if your application opens a cursor, fetches one or more rows, and issues a CICS read with return to the application, upon return your application receives a -135 SQLCODE (INVALID CURSOR STATE) when it attempts to open the cursor, because it was left open from the previous CICS transaction. Or, if the next application attempts to execute a plan with ISOLEVEL=C, your application receives a -144 SQLCODE (INVALID TRANSACTION ISOLEVEL) because you cannot mix transaction isolation levels in the same unit of recovery.

To end the current unit of recovery, have your application issue a ROLLBACK WORK or CICS SYNCPOINT when it receives an unexpected SQLCODE, or you can execute a non-SQL command which ends the current unit of recovery. Otherwise, you must close the SQL User Requirements Table to end the current unit of recovery.

If your application does not execute CICS RETURN with the same transaction ID, the current unit of recovery is ended, that is to say, the unit of recovery is ended if control is passed to another transaction or back to CICS.