search cancel

A cics CTS 5.4 region running Intertest CICS abended with U1800 and 202 abends?

book

Article ID: 190781

calendar_today

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

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.