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
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.