SYSVIEW: CThresholds - LIFETIME and RUNTIME missing information "*"
Article ID: 210125
Updated On:
Products
SYSVIEW Performance Management
Issue/Introduction
LIFETIME and RUNTIME
Setting Thresholds and Alerts...
There are 2 similar alerts LIFETIME and RUNTIME which are flagging high values over the Warning/Problem level.
But when the information is sent to the console(WTO) and to the API, it is missing.
What the transaction is and who is running it.
Both always set to '*'.
What is most interesting is the 'other' RUNTIME event message type - NOT TRANSYS this is TRANDYN and it does include the TranID Tran# and UserID
How to only use the TRANDYN version?
This is what is defined
Variable Jobname Resource1 Resource2
LIFETIME =_______ =_______ =_______
Description Life time of transaction________________
Attributes----------------- Notification---------- Event Capture---------
Rule Type UPPER___ WTO Message YES Trigger Level NONE____
Type SYSTEM__ Log Message YES Interval 00:15:00
Trigger Level STATUS__ SMF Record YES Event Member *_______
Problem Limit 9.000000
Warning Limit 6.750000 OPS/MVS--------------- GSS Intelligent Module
Warning Pct 75_ Notify YES Run NO_
Duration 2__ Event ID CAGSVY0001 IMOD *_______________
Alert Priority 0__
Disabled NO_ SNMP Trap------------- Transaction Cancel----
Schedule------------------- Send NO_ Cancel Action NOCANCEL
Sun Mon Tue Wed Thu Fri Sat Group List *_______ Cancel Limit 10.00000
SUN MON TUE WED THU FRI SAT
Begin Time 00:00:00________
End Time 23:59:59________
Variable Jobname Resource1 Resource2
RUNTIME =_______ =_______ =_______
Description Run time - (LIFETIME-DSPDELAY)__________
Attributes----------------- Notification---------- Event Capture---------
Rule Type UPPER___ WTO Message YES Trigger Level NONE____
Type *_______ Log Message YES Interval 00:15:00
Trigger Level STATUS__ SMF Record YES Event Member *_______
Problem Limit 5.000000
Warning Limit 3.750000 OPS/MVS--------------- GSS Intelligent Module
Warning Pct 75_ Notify NO_ Run NO_
Duration 2__ Event ID CAGSVY0001 IMOD *_______________
Alert Priority 0__
Disabled NO_ SNMP Trap------------- Transaction Cancel----
Schedule------------------- Send NO_ Cancel Action NOCANCEL
Sun Mon Tue Wed Thu Fri Sat Group List *_______ Cancel Limit 30.00000
SUN MON TUE WED THU FRI SAT
Begin Time 00:00:00________
End Time 23:59:59________
And this is what is seeing
LIFETIME
03MAR 06:35:00 CONSOLE MSG GSVC100W GSVC100W (SDCS) TRANSYS TRANS LIFETIME * * NORMAL PROBLEM
03MAR 06:35:00 CONSOLE MSG GSVC100W V= 00:29:59 W= 6.750000 P= 9.000000 UPPER 00:28:00
03MAR 06:35:00 CONSOLE MSG GSVC100W PGCICSWU * * * *
03MAR 06:35:00 CONSOLE MSG GSVC100W Desc='Life time of transaction '
03MAR 06:35:00 CONSOLE MSG GSVC100W Policy=00189F80
03MAR 06:35:00 PGCICSWU API CAGSVY0001 TRANSYS TRANS LIFETIME * * NORMAL PROBLEM V= 00:29:59 W= 6.750000 P= 9.000000 UPPER 00:28:00 PG
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I Variables Values
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.APPLICATION =SYSVIEW
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.VERSION =16.0.01
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.LEVEL =00010990
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.ID =CAGSVY0001
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.COLOR =.
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.GROUP =TRANS
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.NAME =LIFETIME
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.DESCRIPTION =Life time of transaction
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.RSCE1 =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.RSCE2 =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.STATUS =PROBLEM
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.VALUE =00:29:59
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.ELAPSED =00:28:00
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I API.TEXT =TRANSYS TRANS LIFETIME * * NORMAL PROBLEM V= 00:29:59 W= 6.750000 P=
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P01 Exception type =TRANSYS
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P02 Metric group =TRANS
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P03 Metric name =LIFETIME
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P04 Resource 1 =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P05 Resource 2 =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P06 Old metric status =NORMAL
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P07 New metric status =PROBLEM
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P08 'V=' =V=
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P09 Metric value =00:29:59
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P10 'W=' =W=
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P11 Except warn limit =6.750000
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P12 'P=' =P=
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P13 Except problem lmt =9.000000
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P14 Except rule type =UPPER
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P15 time from lst note =00:28:00
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P16 CICS jobname =PGCICSWU
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P17 Transaction ID =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P18 Transaction number =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P19 Terminal ID =*
03MAR 06:35:00 PGCICSWU MSG OPS1000I OPS1000I P20 User ID =*
RUNTIME in TRANSYS format
03MAR 05:11:00 CONSOLE MSG GSVC100W GSVC100W (SDCS) TRANSYS TRANS RUNTIME * * NORMAL PROBLEM
03MAR 05:11:00 CONSOLE MSG GSVC100W V= 5.692974 W= 3.750000 P= 5.000000 UPPER 00:25:59
03MAR 05:11:00 CONSOLE MSG GSVC100W HXBCICS * * * *
03MAR 05:11:00 CONSOLE MSG GSVC100W Desc='Run time - (LIFETIME-DSPDELAY) '
03MAR 05:11:00 CONSOLE MSG GSVC100W Policy=00186970
RUNTINE in TRANDYN format....
03MAR 06:47:15 CONSOLE MSG GSVC100W GSVC100W (SDCS) TRANDYN TRANS RUNTIME HWB2 * NONE PROBLEM
03MAR 06:47:15 CONSOLE MSG GSVC100W V= 14.61769 W= 3.750000 P= 5.000000 UPPER 0.000000
03MAR 06:47:15 CONSOLE MSG GSVC100W HXECICS HWB2 9985 * HXCICS0
03MAR 06:47:15 CONSOLE MSG GSVC100W Desc='Run time - (LIFETIME-DSPDELAY) '
03MAR 06:47:15 CONSOLE MSG GSVC100W Policy=00186970
Environment
Release : 16.0
Component : SYSVIEW
Resolution
Instead of turning off the collection of SYSTEM data, change the threshold. In this case there were 2 thresholds for LIFETIME - one with a TYPE of SYSTEM and the other with a TYPE of TRANS.
The SYSTEM one had OPSMVS set to YES and TRANS was set to NO - Once those were swapped it gives only data for the running transactions and always gives the USERID and TRANSACTION
This also worked the same for RUNTIME
Name Jobname Resourc1 Resourc2 Limit Pct Warning Type RuleType Pri Dur TrigLvl Disabled Count Msg Log SMF OPSMVS
LIFETIME = = = 10.00000 75 7.500000 SYSTEM UPPER 0 2 STATUS NO 1 YES YES YES NO
. = = = 10.00000 75 7.500000 TRANS UPPER 0 2 STATUS NO YES YES YES YES
RUNTIME = = = 9.000000 75 6.750000 TRANS UPPER 0 2 STATUS NO YES YES YES YES
Additional Information
TRANDYN and TRANEND thresholds occur for an individual instance/execution of a transaction.
For example, tran XYZ1 runs, and if it exists long enough it may trip a TRANDYN (TRANDYN is checked on an interval), and/or when it ends it may trip a TRANEND.
02.37.48 STC45508 GSVC500W (SDCS)TRANDYN CICS_TRAN_CICS_LifeTime 608
608 Scope ITC2K155Name XYZ1 Qual * Task 77 Userid CICST
608 V=47.20739 W=45.00000 P=00:01:00 UPPER NORMAL WARNIN
608 0.000000
608 Policy 01173130
For example, tran XYZ1 runs, and if it exists long enough it may trip a TRANDYN (TRANDYN is checked on an interval), and/or when it ends it may trip a TRANEND.
When XYZ1 terminates SYSVIEW also checks the CSTATUS definitions (which are data collection blocks) to see if it matches any of those entries. If it does then the stats for BN3J are added into each matching CSTATUS entry (like LIFETIME = =, CPUTIME = =, etc.).
Out of the box there are fully wildcarded CSTATUS entries for about 19 metrics, including CPUTIME and LIFETIME. So when XYZ1 ends (or any other tranid) it's stats get added into the summary stats for each of those metrics.
Out of the box there are fully wildcarded CSTATUS entries for about 19 metrics, including CPUTIME and LIFETIME. So when XYZ1 ends (or any other tranid) it's stats get added into the summary stats for each of those metrics.
TRANSYS thresholds are processed once a minute, and are processed against the data in these CSTATUS collection blocks for the transaction-level metrics like CPUTIME, LIFETIME, etc.
Take the LIFETIME = entry for example: if 10 trans executed over the past minute, then the LIFETIME value for that entry would be the average lifetime of those 10 trans, which would be compared against any LIFETIME thresholds.
On CSTATUS you can also define your own collection blocks, say specifically for BN3J:
LIFETIME XYZ1 =
LIFETIME XYZ1 =
When a XYZ1 tran ends the lifetime value for it would get added into both the LIFETIME = entry and the LIFETIME XYZ1 entry.
At the end of the minute threshold processing would occur and you could get a GSVC500 TRANSYS trip for both of these entries, Scope ITC2K155 Name = and Scope ITC2K155 Name XYZ1.
At the end of the minute threshold processing would occur and you could get a GSVC500 TRANSYS trip for both of these entries, Scope ITC2K155 Name = and Scope ITC2K155 Name XYZ1.
Any CTHRESH transaction-level thresholds (like CPUTIME, LIFETIME, etc.) that have a Type of * or SYSTEM will be processed against whatever CSTATUS data collection blocks exist for that metric name, as GSVC500 TRANSYS.
A Type of * means that threshold is eligible for both TRANDYN/TRANEND and TRANSYS.
A Type of TRANS means the threshold is eligible only for TRANDYN/TRANEND (a single transaction execution) - no TRANSYS processing will occur for it against the CSTATUS entries.
A Type of * means that threshold is eligible for both TRANDYN/TRANEND and TRANSYS.
A Type of TRANS means the threshold is eligible only for TRANDYN/TRANEND (a single transaction execution) - no TRANSYS processing will occur for it against the CSTATUS entries.
The TSUMxxxx entries are added to CSTATUS automatically, and stats are accumulated in them when transactions end same as described above. Then once a minute any TSUMxxxx CTHRESH entries are processed against the CSTATUS collection buckets and would trip as GSVC500 TRANSUMM.
Please explain why some messages are TRANDYN and others TRANSYS,
TRANSYS is not new, this type of threshold processing has always existed (or at least for a very long time). The specific mention of it is in the help for message GSVC500 (or GSVC100 pre-17.0):
The fields in the message contain the following information:
<type> The type of exception checking.
Possible values:
SYSTEM - System data collection
TRANDYN - Transaction - dynamic
TRANEND - Transaction - end of task
TRANSYS - Transaction - system data
collection
TRANSUMM - Transaction - summary
The * and SYSTEM values for the Type field on RULES are mentioned in the command help (or on CTHRESH pre-17.0):
+------------------+--------------------------------------------------+
| Type | Exception check type. |
| | |
| | This keyword defines the data collection |
| | process type that is eligible to use the |
| | exception definition. |
| | |
| | CICS transaction based metrics can be processed |
| | by the transaction and system data collection |
| | processors. Separate definitions can be created |
| | for each processor. If the "Type" is defined as |
| | "*", then the definition is eligible to be used |
| | by both collection processors. |
| | |
| | Valid values are: |
| | |
| | * - Valid for all collection |
| | processes. If the metric is |
| | not transaction based, specifying |
| | "*" will automatically choose |
| | the correct check type. |
| | |
| | SYSTEM - Only valid for the system data |
| | collection process. |
| | |
| | TIMER - Only valid for timers. |
| | |
| | TRANS - Only valid for the transaction |
| | data collection process. |
| | |
| | TRANSUMM - Only valid for the transaction |
| | summary data collection process. |
| | |
| | This field is displayed if the THRESHOLDS |
| | parameter is specified. |
+------------------+--------------------------------------------------+
All of the threshold processing is done the same as before. The TRANDYN processing is independent of the TRANSYS and TRANSUMM checking.
Just be current on 17.0 maintenance as there were some hiper bugs in this area (LU09757, LU09347, LU08378, LU07350 etc.)
Just be current on 17.0 maintenance as there were some hiper bugs in this area (LU09757, LU09347, LU08378, LU07350 etc.)
Feedback
Yes
No
Powered by
