I don't know what release of SYSVIEW you are running, but in APR 2018 there was a HIPER PTF dealing with incorrect CPUTIME that could also be in play.
Release Apar #
14.2 SO01324
15.0 SO01322
PROBLEM DESCRIPTION:
CPU time is not being calculated properly for active CICS transactions.
The CPUTIME data collection variable for a transaction may be
inaccurate, specifically if a transaction is in a hard loop or other
intensive processing where it does not give control back to CICS or
get suspended.
SYMPTOMS:
An actively executing transaction, identified on the CTASKS display
with a highlighted Tran id and a ">" in the 'A' column, may not show
an increasing value in the CPUTime field even though it is consuming
CPU. Likewise, any defined CPUTIME thresholds will not trigger (or
potentially cancel) the transaction since the value is not increasing.
Note that when the transaction ends the resulting CTRANLOG transaction
detail record does contain the accurate CPU time.
IMPACT:
Runaway transactions may not be identified and/or cancelled, possibly
possibly resulting in a performance impact to the region. However, any
native CICS AICA runaway processing would still be in effect.
------------------------------
Software Engineer
Broadcom
------------------------------
Original Message:
Sent: 07-15-2019 12:21 PM
From: Douglas Miller
Subject: CA-Sysview/CICS : no threshold-cancel performed, even though in 'AICA' situation
Peter,
SYSVIEW performs threshold checking for executing transactions on an interval, which is the Every value for the TRAN-THRESHOLDS entry on CSCHEDUL. The default is every 15 seconds. So depending on where that checking interval falls the transaction could have reached the ICVR before SYSVIEW checked it the next time around.
------------------------------
Software Engineer
Broadcom
Original Message:
Sent: 07-10-2019 03:54 AM
From: PETER DE WOLF
Subject: CA-Sysview/CICS : no threshold-cancel performed, even though in 'AICA' situation
Hi,
in one of our CICS regions we encountered 2 similar situations, and I was wondering if anyone had any thoughts about it.
Setting: We have a CPU-threshold set (via CTHRESH), to kill a task after exceeding the limit of 10 CPU-Secs.
Situation 1:
- threshold limit is exceeded, Sysview intervenes and performs a KILL of the task;
- Unfortunately KILL does not get through;
- After 20 CPU-seconds (ICVR-value in CICS) the task gets an abend AICA, and then followed by an abend AKKE (=result of the KILL)
Situation 2:
- same transaction, CTHRESH is exceeded, but this time Sysview does *not* intervene;
- After 20 seconds the AICA kicks in and the task is purged;
So basically: 2 AICA situations, and in one situation the CTHRESH is trying to do its work, and in the other situation it doesn't do anything.