Insight Exception not Tripping

Products

• Bind Analyzer for DB2 for z/OS
• SQL-Ease for DB2 for z/OS
• SYSVIEW Performance Management Option for DB2 for z/OS
• Plan Analyzer for DB2 for z/OS
• Subsystem Analyzer for DB2 for z/OS

Issue/Introduction

User set up insight DB2 exception on a production system few weeks back as seen below:  

ACTIVE ****  EJB1-High percentage of maximum REMOTE threads in  

              use during the last exception interval =&VALUEXX%  

 Specify which levels are active and their threshold values:            

  Informational active?  . : Y (Y or N)   Threshold value . : 225      

  Warning active?  . . . . : Y (Y or N)   Threshold value . : 340      

  Critical active? . . . . : Y (Y or N)   Threshold value . : 495      

                      Logging and Notification Controls                      

  Change the logging and notification options below.  Then press Enter.      

  Log exception starting at level . . . . . . . . . . : W (I=Info, W=Warn, 

                                                            C=Crit, N=None) 

  Number of times exception will occur before logging : 1                  

  Send to TSO user #1 . :          starting at level  : N (I=Info, W=Warn, 

  Send to TSO user #2 . :          starting at level  : N  C=Crit, N=None) 

  Send to TSO user #3 . :          starting at level  : N                  

Issue WTO starting at level . . . . . . . . . . . . : W (I=Info, W=Warn, 

   Hold the WTO starting at level  . . . . . . . . . . : C  C=Crit, N=None) 

   Issue Multi-Line WTO or 2 Single WTO's  . . . . . . : S (M=Mult, S=Sngl)

When the limit is hit, the exception didn't trip. Here is the history

 

From 01/03/17 07:00:00 To 01/03/17 13:00:00                                                    

  End               Thread                        SQL             Total DB2 CPU CTHREAD MAXDBAT

  Time     Excptns   Terms  Commits   Aborts    Stmts Getpages      I/O H:MM:SS Int HWM Int HWM

  -------- ------- ------- -------- -------- -------- -------- -------- ------- ------- -------

. 10:30:00       4   12934  4661875     9851  171952K  549501K 32345084   18:36     335      46

. 11:00:00       3   13573  4451990    10147  163281K  519264K 31415697   17:59     335      52

. 11:30:00       3    9447  4184620     7881  155355K  479155K 29146455   16:52     316      48

. 12:00:00       5   10784  3896549     8040  146715K  468423K 27687386   15:23     558     450

. 12:30:00       5   12457  3510037     7153  138719K  418914K 24547980   14:37     640     450

. 13:00:00       3   16026  3509232     7894  147061K  485679K 29066928   17:14     444     210

 

 

Environment

Release:
Component: CIDB

Resolution

User Subsystem exception type is: "Percentage of one cumulative/snapshot field value over another ". So the threshold value being checked in this exception is a percentage. It appears that he had coded threshold values for the actual number of remote threads in use.  So any value over 100 will never trip, since once the max out the available thread connections, no new ones are created. 

That explains why the development exception actually tripped, since user is using threshold values like 64 and 96. It explains why there was a warning exception message displayed in the development DC jes log where the message showed it was at 100%. user picked up a different exception and it the correct exception.