ASP7: Syncpoint backed out after a NO vote
An ASP7 abend means that during a syncpoint, one of the resource managers taking part in the unit of work, such as Db2 or CICS event processing, voted no in the prepare phase. CICS backed out the whole unit of work and abended the transaction.
Other names for this code
Also written as ASP7 abend, CICS ASP7, abend ASP7, abendASP7, ASP7 syncpoint, ASP7 event processing.
What it means
A CICS unit of work can update several kinds of resource at once, such as CICS files, Db2 tables and MQ queues. To keep them in step, CICS commits them with a two-phase commit. When the task takes a syncpoint, either with EXEC CICS SYNCPOINT or by ending, CICS first asks every participant whether it is ready to commit. This is the prepare phase. If all of them say yes, CICS tells them to commit. If any of them says no, none of them commit and everything is backed out.
ASP7 is how the task learns that a participant said no. The transaction ends abnormally and its recoverable updates are backed out. In an IBM APAR the region reported it with message DFHAC2249, saying the transaction had failed with abend ASP7 and that updates would be backed out. There, the recovery manager trace showed Db2 had voted no.
CICS event processing is another participant that can vote no. If a synchronous event can't be emitted, CICS backs out the unit of work that raised it and issues ASP7. IBM points out that ASP7 also has causes unrelated to events, so the first job is to work out which participant voted no.
Common causes
- Db2 voted no during prepare. In IBM APAR PI82188 the Db2 trace showed reason code 00F30048 on the prepare call, and the root cause was a CICS defect that gave two tasks the same unit of work ID.
- A synchronous event in an event binding couldn't be emitted. Common reasons are an EP adapter program that isn't defined or enabled, an EP adapter that abended, or message queues that are missing or have the wrong attributes for the event.
- Another resource manager taking part in the unit of work, such as one attached through a task-related user exit, voted no.
How to find the problem
- Find the DFHAC message for the ASP7 in the region's message log, and read the messages from Db2, MQ and event processing just before it.
- For event processing, look for exception trace entry AP 05AE shortly before the abend. If it's there, find message
DFHEC1022, which names the event binding. In a long-running task DFHEC1022 can appear well before the abend, because it is written at the first failed event and the abend comes at commit. - An exception trace entry 040A means the link to the EP adapter failed, and the entry gives the reason.
- If event processing isn't involved, recovery manager trace entries show which participant voted no. IBM used this to find the Db2 vote in PI82188.
How to fix it
- If the event shouldn't have been captured at all, narrow the capture specification filters in the event binding and redeploy it.
- If the event should have been emitted, fix the EP adapter definition or the queues it uses, then rerun the transaction.
- If Db2 or another resource manager voted no, follow its own messages, and check IBM's APARs for your release if nothing explains it.
- Rerunning the transaction is safe once the cause is fixed. The whole unit of work was backed out, so nothing is applied twice.
IBM documentation
IBM documentation: ASP7. Use the documentation for your installed release.
Related codes
Questions
Why did ASP7 happen at the end of the transaction and not earlier?
The vote happens at syncpoint, which is often when the task ends. With event processing, the failed event may have been logged in DFHEC1022 long before the abend.
Were my updates committed?
No. When any participant votes no, CICS backs out the whole unit of work, including the changes held by the participants that voted yes.
How is ASP7 different from ASP3?
ASP3 means a remote coordinator, such as another CICS region, decided the unit of work must be backed out. ASP7 means a participant voted no when it was asked to prepare.