SQLCODE -926: ROLLBACK not valid in IMS, CICS or RRSAF
SQLCODE -926 (SQLSTATE 2D521) means the program issued an SQL ROLLBACK in an IMS or CICS transaction, or under RRSAF when Db2 isn't the only resource manager. Db2 doesn't run it, and no changes are backed out.
Other names for this code
Also written as SQL -926, SQLCODE=-926, SQLCODE = -926, db2 -926, sqlstate 2D521, SQL0926N, rollback not valid in ims cics or rrsaf environment.
What it means
-926 is the ROLLBACK twin of -925. Under CICS and IMS, the transaction manager controls the unit of work for every resource the transaction touches. Under RRSAF, z/OS RRS does the same when more than one resource manager is involved. Db2 can't back out its own part alone, so SQL ROLLBACK is rejected.
This one matters more than -925. A program usually issues ROLLBACK because something went wrong. If it then assumes the changes are gone and carries on, the bad changes are still there and will be committed at the next sync point unless something else backs them out.
Db2 for LUW uses SQL0926N with the same SQLSTATE for similar environments.
The usual shape of the bug is an error routine shared between batch and online code. In batch, SQL ROLLBACK works and the routine was tested there. Under CICS it returns -926, the routine doesn't check, and the transaction goes on to its normal SYNCPOINT, which commits the changes the routine meant to undo.
Common causes
- Error handling copied from a batch program uses EXEC SQL ROLLBACK inside a CICS or IMS transaction.
- A shared subroutine issues ROLLBACK and is called from both batch and online code.
- An RRSAF program uses SQL ROLLBACK while RRS coordinates several resource managers.
- A program checks the SQLCODE after its updates but not after its ROLLBACK, so a -926 in an error path goes unnoticed.
How to find the problem
- Search the program and its subroutines for
EXEC SQL ROLLBACK, usually in error paths. - Check whether the program went on to commit work after the ROLLBACK failed, which would keep changes it meant to undo.
- Confirm the environment from the CICS transaction, the IMS region or the RRSAF connection.
- In CICS, an auxiliary trace or a monitor such as CICS PA can show whether the task reached a normal SYNCPOINT after the failed ROLLBACK.
How to fix it
- In CICS, use
EXEC CICS SYNCPOINT ROLLBACK. - In IMS, back out through IMS, for example with a roll back call, or end the transaction abnormally so IMS backs it out.
- Under RRSAF with several resource managers, back out through RRS with SRRBACK.
- Check the SQLCODE after every ROLLBACK, so a -926 can't pass unnoticed and let bad data be committed.
What it looks like
DSNT408I SQLCODE = -926, ERROR: ROLLBACK NOT VALID IN IMS, CICS OR RRSAF ENVIRONMENT DSNT418I SQLSTATE = 2D521 SQLSTATE RETURN CODE
IBM documentation
IBM documentation: -926. Use the documentation for your installed release.
Related codes
Questions
Were my changes backed out after -926?
No. Nothing was rolled back. Back them out through CICS, IMS or RRS, or they may be committed later.
What should a CICS program use instead?
EXEC CICS SYNCPOINT ROLLBACK. It backs out Db2 changes and other recoverable resources together.
Do -925 and -926 share an SQLSTATE?
Yes. Both return SQLSTATE 2D521, so check the SQLCODE to see whether a COMMIT or a ROLLBACK was rejected.