Multiple GSVC100W messages for STGVTRAN threshold

Products

• SYSVIEW Performance Management
• NXBRIDGE - SYSVIEW/ENDEVOR

Issue/Introduction

We are attempting to set up SYSVIEW alerting for CICS storage violations and had a STGVTRAN rule in place for a while.The region in question had three actual DFHSM0102 messages in a prior run, but a disproportionately large number of GSVC100W messages were issued in the subsequent run--nearly 24 hours into the run--and continued for over an hour until the region was canceled. According to your doc, we should be seeing a GSVC118W message, not the GSVC100W message. We are looking for assistance in understanding the storage violation threshold rules, and whether any logging of pertinent storage violation data (e.g. the exception trace entry contents) is possible.
Sample GSVC100W messages seen:

19.29.49 STC52979 GSVC100W (TPPT) TRANEND TRANS STGVTRAN RS6I -AAJ NONE PROBLEM 279 279 V= 0 W= 0 P= 0 UPPER 0.000000 279 C$SPPT01 RS6I 47375 -AAJ CAFEX 279 Desc='Storage violations for transaction ' 279 Policy=0006FC38
19.29.49 STC52979 xxxxxx 31/07/2018 19:29:49 SOCKET ERROR CONN=1HC000 C 19.29.49 STC52979 GSVC100W (TPPT) TRANEND TRANS STGVTRAN OFZ1 * NONE PROBLEM 281 281 V= 0 W= 0 P= 0 UPPER 0.000000 281 C$SPPT01 OFZ1 45450 * CAFEX 281 Desc='Storage violations for transaction ' 281 Policy=0006FC38
19.29.49 STC52979 GSVC100W (TPPT) TRANEND TRANS STGVTRAN RS6I -ACJ NONE PROBLEM 282 282 V= 0 W= 0 P= 0 UPPER 0.000000 282 C$SPPT01 RS6I 47376 -ACJ CAFEX 282 Desc='Storage violations for transaction ' 282 Policy=0006FC38

As you can see, these were coming out multiple times per second, but no DFHSM0102 messages were seen to go with them. Can someone explain how our setup might have caused this to happen, or is this an issue with SYSVIEW itself?
SYSVIEW is at release 15.0, and CICS is at 5.2. 

Environment

Release:
Component: SYSVW

Resolution

Based on the messages, it looks like you have a CTHRESH definition for the metric STGVTRAN set with a limit value of 0. This will trigger on every transaction. It would read as "If the number of storage violations for a transaction is greater than or equal to the limit value (0), trigger the definition and actions. In many cases the transaction executing when CICS recognizes the storage violation is not necessarily the one that caused it, but the victim.
We do not claim that the transaction ID listed in the message caused the violation. It is the transaction in control when discovered. In many cases, if the same transaction repeatedly finds a storage violation, it might also be the offender.