How SYSVIEW CICS CPUTIME Metric works

Products

• SYSVIEW Performance Management

Issue/Introduction

Using  CPUTIME Metric to monitor the amount of CPUTIME transactions, it is possible to see messages showing the status Value changing  from Normal to Warning to problem, but never seen a transaction threshold return back to a status of NORMAL.

DEFINE     CPUTIME  ENABLED                                       
  JOBNAME  =         RSCE1 #WWW     RSCE2 =                        
  RULETYPE UPPER    TYPE     TRANS    TRIGLVL CHANGE   PRIORITY 0  
  LIMIT    10.00000 WARNING  7.500000 WARNPCT 75       DURATION 2  

Resolution

The results are the expected ones, based on the CPUTIME TYPE TRANS threshold definition.

 
CPUTIME is a transaction level threshold.  

There are two types of transaction level thresholds, defined by the TYPE parameter on the definition: SYSTEM and TRANS (a value of * means the definition will be used for both types).
 
TYPE TRANS applies to a single instance/execution of a transaction.  

As each individual transaction runs and ends, threshold processing is performed for it alone.
While a transaction is running threshold processing is performed for it on the interval specified on the TRAN-THRESHOLDS event on CSCHEDUL.

Alerts triggered by this interval checking will show as TRANDYN.  

If the transaction runs long enough to cross several of these intervals you may see the status change from NORMAL => WARNING => PROBLEM.
When that same transaction ends threshold processing is performed again from scratch (if THRESHOLD-TASK-END  YES  on CCONFIG).  

Alerts triggered at this time will show as TRANEND.  

The status will change from NONE to WARNING or PROBLEM.  

This transaction end processing is independent of the interval based checking done while the transaction is running, so the 'old' status on TRANEND will always be NONE.

Many transactions will run quick enough that you may not often see a TRANDYN for it, but could see a TRANEND if it exceeds the limit.
Since TYPE TRANS is for an individual instance of a transaction, which at some point ends, there is no concept of it going back to NORMAL.

While dealing with an instance of a transaction, it doesn't really make sense to return to normal, the transaction just ends at some point.

However, setting THRESHOLD-TASK-END  YES  then  a TRANEND threshold will occur when it terminates. 

Since transaction thresholding on currently executing transactions only occurs on an interval (that could be few seconds) it is possible to not get a TRANDYN but then get a TRANEND when it terminates.

TYPE SYSTEM applies to a collection of transactions that ran over the specified DURATION.
Say you have a threshold for CPUTIME RSCE1 =.

As each/any transaction runs it's CPUTIME stat is added to a 'bucket'.  

At the end of each minute the values in the bucket are averaged and then compared to the threshold limit.

Alerts triggered by this interval checking will show as TRANSYS.

You may see the status for TRANSYS change from NORMAL => WARNING => PROBLEM, or even back to NORMAL on successive intervals.

The 'back to NORMAL' is possible here since this set of data has a historical set of collection buckets to compare from one interval to the next.
 
Note that a requirement for a TYPE SYSTEM transaction threshold is that the collection bucket referred to above must be defined for the RSCE1 value. This is done on the CSTATUS display (or CICSSTAT parmlib member).  

The above example would require a CSTATUS definition for CPUTIME =.  

In case, we wanted to have threshold CPUTIME TYPE SYSTEM for RSCE1 #WWW, then we'd need a definition on CSTATUS for CPUTIME #WWW for the stats to be accumulated in to.

The TSUMxxxx thresholds (TYPE TRANSUMM) are similar to the TYPE SYSTEM transaction level ones.  

They both operate off of the collection buckets seen on CSTATUS, and threshold processing is done each minute.  

The main difference is SYSVIEW automatically defines the CSTATUS entries for the TSUMxxxx metrics for any tranids it has seen, as well as for any CICSTRAN groups you've created.

THRESHOLD-TASK-END plays no role for TRANSYS or TRANSUMM alerts.  It solely controls whether the TRANEND threshold check occurs after the transaction terminates.