search cancel

SOLVE/NetMaster - EventView rules ranked incorrectly


Article ID: 199535


Updated On:


SOLVE:Operations Automation SOLVE: Access Session Management SOLVE:Access Session Management SOLVE:FTS MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME


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   164.53.216.
1                CT   164.53.232.
1                CT   10.45.157. 
1                CT   10.46.157. 
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. 


Release : 11.9

Component : CA SOLVE:Operations Automation for z/OS


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.