Question & Answer
Question
Why do I occasionally receive message DFHAP0002 A severe error (code X'3191') has occurred in module DFHD2EX1 when purging a CICS Transaction Server for z/OS (CICS TS) task?
Cause
The DFHAP0002 3191 message and dump generally occurs because the purge happens to catch the task while control is in DB2 for a SYNCPOINT PREPARE request.
The Kernel error table in the AP0002 dump shows the sequence of abends for the task that occurred after the purge. You can format the Kernel domain with IPCS command VERBX DFHPDxxx 'KE=1' where xxx is your release level of CICS like 730 for CICS TS 5.6.
ERR_NUM ERR_TIME KE_NUM ERROR TYPE ERR_CODE MODULE OFFSET
======= ======== ====== ========== ======== ====== ======
00000001 18:50:33 03DA ABEND ---/0999 UNKNOWN UNKNOWN
00000002 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/AD2R DFHPCP 000005E8
00000003 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/AD2R DFHD2EX1 00002CAE
00000004 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/AD2R DFHERM 00001352
00000005 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/AD2R DFHERMSP 00000D3C
00000006 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/ASP7 DFHPCP 000005E8
00000007 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/ASP7 DFHSPP 00000526
00000008 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/ASP7 DFHEISP 00000626
00000009 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/ASP7 DFHEIP 000008AC
0000000A 18:50:33 03DA TRAN_ABEND_PERCOLATE ---/ASP7 DFHEPC 00000246
When the purge is started, control of the task is over in the DB2 address space. The associated L8 TCB is abended with a 999 (x'3E7') abend code, and an AD2R abend is started for the task. When CICS percolates the error back through previously called modules, an ASP7 abend is started because of the failure to commit this unit of work. CICS then starts backout processing. However, when CICS is about to call DB2 for backout, an attempt is made to change the task back onto the L8 TCB it was running on, but the L8 TCB has gone away as a result of the 999 abend. So the DFHAP0002 x'3191' message is issued indicating that the L8 TCB is gone, along with corresponding exception trace entry:
AP 3191 D2EX1 EXC - LOST_OUR_THREAD
You can see the exception trace entry by formatting the CICS internal trace table with VERBX DFHPDxxx 'TR=2'.
Answer
Alternatively, make sure that you have applied the PTFs for DB2 APAR PI92893 to DB2 V11.1 and V12.1:
- DB2 V11.1 (RB10) UI55526 UP18/05/15 P F805
- DB2 V12.1 (RC10) UI55522 UP18/05/12 P F805
Topic CEMT SET PURGE in the CICS TS 6.1 documentation states:
When purging or forcepurging a task, if CICS® detects that the task has a Db2® thread currently active in Db2, CICS issues a Db2 cancel thread request before proceeding with the purge of the CICS task. This ensures that the purge does not cause problems for Db2 and that the Db2 updates are safely backed out. If the task has a Db2 thread but it is not currently active in Db2, then a cancel thread is not required. The Db2 thread is used as normal to back out the Db2 updates when CICS backs out the unit of work as a result of the purge of the task. This capability requires APAR PI92893 on Db2 Version 12 (and 11). No APAR is needed for higher releases of Db2.
CICS TS V5.1 APAR PI98569 provides PTFs for CICS TS 5.1, 5.2, 5,.3, and 5.4 which change CICS to cancel the DB2 thread as part of the CICS purge processing. These updates are in the base code of CICS TS V5.6 and higher. Without these changes, there is a risk associated with purging tasks while control is in Db2, even the Db2 subsystem can abend.
Product Synonym
CICS/TS CICSTS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
24 October 2023
UID
dwa1180645