SOLVE/NetMaster - EventView rules ranked incorrectly
Article ID: 199535
Updated On:
Products
Issue/Introduction
We have encountered a situation where Eventview rules are being ranked incorrectly. We have the following three rules defined essentially to perform different processing for specific IP addresses:
Rule 1:
Message Text: I0* ******** NS000
Extended Filter:
Strt Word Scan
Pos Num Opr Text
7 EQ TZ001
1 CT xxx.xx.xxx.
1 CT xxx.xx.xxx.
1 CT xx.xx.xxx.
1 CT xx.xx.xxx.
Expression: 1 AND (2 OR 3 OR 4 OR 5)
Rule 2:
Message Text: I0* ******** NS000
Extended Filter:
Strt Word Scan
Pos Num Opr Text
7 EQ TZ001
1 CT 10.41.132.
Expression: 1 AND 2
Rule 3:
Message Text: I0* ******** NS000
Extended Filter:
Strt Word Scan
Pos Num Opr Text
7 EQ TX001
7 EQ TZ001
7 EQ VT001
Expression: 1 OR 2 OR 3
Rule 1 and Rule 3 have existed for quite some time and been working successfully. We set up Rule 2 recently when a new IP address was requested and there was no room to add it to Rule 1. But what we've found is that messages that should match Rule 2 are instead being actioned by Rule 3. Messages that match Rule 1 are still being actioned correctly.
Since detecting the problem testing has shown that removing one or both of TX001 and VT001 from Rule 3 results in messages matching Rule 2 as they should. The issue seems to be having three text matches in Rule 3.
Environment
Release : 11.9
Component : CA SOLVE:Operations Automation for z/OS
Resolution
The rule rank is made up of these factors:
First 2 digits – if no priority specified the default is 99 (otherwise it will be the priority assigned in the rule)
Next 2 digits – this is a default of 99 minus the length of the message text specified in the rule (with some extra calculation done based on wildcards and number of words)
Next digit – this is the number of days of the week that the rule is active (the fewer days the better the better the rank - default is 7)
Next 2 digits – the number of hours the rule is active each day (fewer hours – better rank - default is 24)
Last two digits – derived from various factors in the rule. We start with a value of 99 and then:
** Subtract 2 for each extended filter line
** Subtract 2 for each EventView variable created
** Subtract 2 for each of the following filter criteria in the rule
* System
* Job name
* Job type
* Route code
* Descriptor code
** Subtract 1 for each of the following message modifications in the rule
* DELIVER = NO
* NRD = YES or OPER
* Monitor Class = YES
* Alarm = YES
* Replacement Text present
All three rules get the same value for the first 7 digits, but the last two digits are what are bringing you undone.
Rule 1 gets 89. Rule 2 ends up with a figure of 95 while rule 3 gets 93 because of the extra line of extended filter expression. As you have seen removing one line of extended filter brings it back to 95 like rule 2 and rule 2 is actioned (but only because you have updated Rule 3 more recently and Rule 2 gets looked at first. If you go back and update Rule 2 then Rule 3 will be executed as it will be looked at first.
The easiest way to fix this would be to give Rule 2 a priority of 98 or add a couple of lines to the extended filter and make them OR conditions that won't matter one way or the other.
Feedback
