A cics CTS 5.4 region running Intertest CICS abended with U1800 and 202 abends?
Article ID: 190781
Updated On:
Products
InterTest - CICS
Issue/Introduction
We had a CICS region abend with a U1800. We opened case with IBM and they have indicated the issues was caused by CA Intertest CICS
CTS 5.4 Intertest Release 11
IBM response
We had a CICs region abend with a U1800, after getting 202 abends. We opened a case with
IBM and they have indicated the issue was caused by CA Intertest-CICS
The joblogs showed lots of components taking POST failures with abend 202s reported by IEAVEPST, and DFHDS0001, DFHAP0701 and IEA995I messages.
Kernel error information shows that the problems began with an abend 301:
ERR_NUM ERR_TIME KE_NUM ERROR TYPE ERR_CODE MODULE OFFSET
======= ======== ====== ========== ======== ====== ======
000051EE 14:05:35 0002 ABEND 301/AKEB DFHDSDS3 00000E38
000051EF 14:05:54 0085 ABEND 202/AKEB DFHDSSR 00001402
MVS error processing for the abend301 will leave other ECBs in the CICS wait list in an inconsistent state leading to the abend202/POST errors.
The abend 301 occurs due to a duplicate wait on an ECB. R6 from the MVS registers at abend301 show that the ECB causing the problem is at address 000DC6AC. Dispatcher domain confirms that there are 2 tasks waiting on this same ECB. Here are the 2 tasks waiting on ECB 000DC6AC:
Task# Tran Resource Resource Time of ECB addr
Type Name Suspend (SUSPAREA)
------------------------------------------------------------------------------------------
48909 NNAD EKCWAIT SINGLE 13:22:13.006 000DC6AC
04653 RE15 EKCWAIT SINGLE 14:05:26.399 000DC6AC
Note that task NNAD/48909 had been suspended for over 1 day, since 2/14; the abend301 occurred on 2/15.
For both tasks, it is program IN71PGMS +x'AEC0' who issued the EXEC CICS WAIT EVENT passing the duplicate ECB, DC6AC. IN71PGMS appears to be a CA INTERTEST module. The ECB, DC6AC lives in shared storage.
The abend202 POST failures occurred as fallout from an abend301. The abend301 occurred because of a duplicate wait on an ECB by program IN71PGMS +x'AEC0' which appears to be CA INTERTEST. I suggest contacting CA for this problem
IBM and they have indicated the issue was caused by CA Intertest-CICS
The joblogs showed lots of components taking POST failures with abend 202s reported by IEAVEPST, and DFHDS0001, DFHAP0701 and IEA995I messages.
Kernel error information shows that the problems began with an abend 301:
ERR_NUM ERR_TIME KE_NUM ERROR TYPE ERR_CODE MODULE OFFSET
======= ======== ====== ========== ======== ====== ======
000051EE 14:05:35 0002 ABEND 301/AKEB DFHDSDS3 00000E38
000051EF 14:05:54 0085 ABEND 202/AKEB DFHDSSR 00001402
MVS error processing for the abend301 will leave other ECBs in the CICS wait list in an inconsistent state leading to the abend202/POST errors.
The abend 301 occurs due to a duplicate wait on an ECB. R6 from the MVS registers at abend301 show that the ECB causing the problem is at address 000DC6AC. Dispatcher domain confirms that there are 2 tasks waiting on this same ECB. Here are the 2 tasks waiting on ECB 000DC6AC:
Task# Tran Resource Resource Time of ECB addr
Type Name Suspend (SUSPAREA)
------------------------------------------------------------------------------------------
48909 NNAD EKCWAIT SINGLE 13:22:13.006 000DC6AC
04653 RE15 EKCWAIT SINGLE 14:05:26.399 000DC6AC
Note that task NNAD/48909 had been suspended for over 1 day, since 2/14; the abend301 occurred on 2/15.
For both tasks, it is program IN71PGMS +x'AEC0' who issued the EXEC CICS WAIT EVENT passing the duplicate ECB, DC6AC. IN71PGMS appears to be a CA INTERTEST module. The ECB, DC6AC lives in shared storage.
The abend202 POST failures occurred as fallout from an abend301. The abend301 occurred because of a duplicate wait on an ECB by program IN71PGMS +x'AEC0' which appears to be CA INTERTEST. I suggest contacting CA for this problem
Environment
Z/OS
CICS
Cause
The CICS MSGUSR shows an attempt to purge the Intertest CICS ISER long running task that is required for InterTest for CICS to properly function in CICS.
Resolution
In the most recent MSGUSR file that you sent in it shows an attempt to purge the ISER long running task that is required for InterTest for CICS. In fact, it shows two attempts to purge this task.
DFHAP1900 DATE TIME TCICSRJE NONE TSEQ ISER SET TASK(36420) PURGETYPE(FORCEPURGE) RESP(NORMAL) RESP2(0).
Despite the purge, the ISER task continues to run and another ISER task is started up and this can cause the posting of the duplicate wait on an ECB.
The ISER task is started when InterTest starts up from the PLT (or the CNTL=START command) and must continue to run for Intertest CICS to function properly. So the task should not be purged. If the purge request is a
result of a "purge of long running tasks", by OMEGAMON for example, then this task should be excluded from the list.
If it is necessary for some reason to stop this task from executing, the best way to do that would be to terminate InterTest and restart it using the CNTL=END and CNTL=START requests.
DFHAP1900 DATE TIME TCICSRJE NONE TSEQ ISER SET TASK(36420) PURGETYPE(FORCEPURGE) RESP(NORMAL) RESP2(0).
Despite the purge, the ISER task continues to run and another ISER task is started up and this can cause the posting of the duplicate wait on an ECB.
The ISER task is started when InterTest starts up from the PLT (or the CNTL=START command) and must continue to run for Intertest CICS to function properly. So the task should not be purged. If the purge request is a
result of a "purge of long running tasks", by OMEGAMON for example, then this task should be excluded from the list.
If it is necessary for some reason to stop this task from executing, the best way to do that would be to terminate InterTest and restart it using the CNTL=END and CNTL=START requests.
Feedback
Yes
No
Powered by
