We have defined metric STGVIOLS - Storage violation in CTHresh and setup is like that:
So.. The problem is that even if the metric didnt reach the alert limit, we will get a WTO message. No message in XLOG but lot of in SYSLOG. Also Count has 0 value which is correct bacause no storage violation was reached but why i get those false GSVC118W msg in syslog.
The message what i've get into syslog are:
GSVC118W (Task) TRAN dump 4039 42/0001 Tran ZI7D * Program PZI7DP0 Term 2349 Userid S4345 AbCode *
GSVC118W (Task) TRAN dump AEXY 42/0010 Tran RMUA * Program PRMUAUH Term <AF2 Userid S4382 AbCode *
Lot of per/day
Q.1 If Count in 0. The message shouldnt be triggered anywhere. Is it correct ?
Q.2 The messageID GSVC118W is only for those 2 metric : STGVIOLS, STGVTRAN Is it correct ?
Q.3 Why I get those messages into syslog, am I missing something ?
The count for STGVIOLS shows a value of zero because that threshold has not triggered. The GSVC118W message is not particular to the variables STGVIOLS and STGVTRAN. This message is signifying that CICS has requested a dump be taken. If you desire to pursue this further, it is recommended that you open a case with CA Sysview support.
There are two flavors of the GSVC118W.
One is for STGVIOLS and the other is for STGVTRAN.
For a complete explanation please see:
CICS Storage Violation Monitoring - CA SYSVIEW® Performance Management - 14.2 - CA Technologies Documentation
If you are unable to determine the cause (STGVTRAN in this case) please open a case with SYSVIEW Support
-Bob Brandl, CA SYSVIEW Support Team
Thank you for your questions.
The information on the reference page in the previous update is not 100% accurate. I am having it fixed now, but until then, here is some accurate information in further detail:
The STGVIOLS metric is not related to either the STGVTRAN metric nor the GSVC118W message. STGVIOLS is collected at the system level, not the transaction level, so I am not going to talk about STGVIOLS in my answer as it is unrelated to your questions.
The GSVC118W message and the STGVTRAN metric, while they are closely related, are mostly mutually exclusive of one another.
The GSVC118W message and the STGVTRAN metric are related in that you must have the SYSVIEW/CICS CCONFIG option DUMP-MANAGEMENT set to YES for either of them to function. After that, there is no correlation between them.
The GSVC118W message is created when the CICS dump exit point detects there was a request by CICS to take a dump. It really has nothing to do with a storage violation other than a dump might be taken as a result of a storage violation. When this occurs, and the DUMP-MANAGEMENT option is set to YES, SYSVIEW will unconditionally create a GSVC118W message regardless of a STGVIOLS metric threshold. If you are seeing many of these GSVC118W messages, while it may be a nuisance, it should probably be further reviewed by the CICS application owners for errors. I would think you should not see dumps with that much regularity as you are.
Also note that at SYSVIEW 15.0 feature PTF 6 (SO00378) which was released in February, 2018, the behavior of the GSVC118W message was slightly altered.
If you just recently started to see more of these messaged and you have PTF 6 installed, this could be the reason.
If you wish, you can suppress the GSVC118W message from within SYSVIEW. In the MESSAGES parmlib member, you can add an entry that looks like this:
ACTION W NOROUTECODE 2
This will prevent SYSVIEW from writing the message to the system log. The message will still be written to the GSVCLOG DD in the CICS region. Note, after making the parmlib update, you will need RELOAD the member on the LIBCACHE command, then recycle SYSVIEW in CICS (GSVT/GSVS) for this change to take effect.
Alternatively, if you are not using the STGVTRAN metric, and you are not relying on the GSVC118W message, and you are not using the DUMP section in the CICS transaction records (viewed from selecting a record on CTRANLOG) you can safely set DUMP-MANAGEMENT to NO and avoid the messages that way.
Please let me know if you have any questions.