| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1428.1 | Wildcards not allowed within the CHANGE_OF function | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Sep 03 1991 12:50 | 9 |
| >> This alarm works if I specify a specific remote node.
>> Why can I show the remote nodes via a wild card but not use a
>> wild card in an alarm rule?
The CHANGE_OF function cannot accept wildcarded entity instances.
This is why you get the 'Valid entity specification not found...' error
message.
/keith
|
| 1428.2 | | KAOT01::S_HYNDMAN | | Tue Sep 03 1991 13:49 | 8 |
|
Thats a shame. I'll have to create alot more rules.
Thanks for the reply.
Scott
|
| 1428.3 | Try collecting the DECnet event.... | TOOK::CAREY | | Fri Sep 06 1991 18:11 | 17 |
|
Play with events.
The DECnet event "node reachability change" can be used to have a
routing node tell you when nodes it used to know about disappear.
Set up a nearby router to sink events 4.14 to your MCC node, set up the
MCC node to sink the events to you, and use an alarms rule something
like:
OCCURS(NODE4 router REMOTE NODE * NODE REACHABILITY CHANGE)
This will reduce your polling overhead on system and network, and get
you the same information in as timely a manner.
-Jim
|
| 1428.4 | | KAOT01::S_HYNDMAN | | Tue Sep 10 1991 14:40 | 22 |
|
By a stroke of luck, I was able to use event sinks from the x25routers.
I currently have 13 X25 routers sinking events back over DLM circuits
to my mcc system. I set up rules as follows;
(occurs(node4 router1 circuit ethernet adjacent node * adjacency down))
(occurs(node4 router1 circuit ethernet adjacent node * adjacency up))
I considered the rule you indicated. I decided against it because
the X25 routers have DLM circuits to each other, and figured that I
would get duplicate alarms from each router any time one went away.
Since the Iconic map displays were the event was reported, not
the node with the problem, all my routers would turn red. This would
be very confusing for the operators.
Thanks for your input.
Scott
|
| 1428.5 | how would you retarget these? | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Fri Sep 20 1991 10:11 | 40 |
|
If you have a minute to think about your problem (wrong icon turning
a color), I would be intersted in knowing how you would retarget the
event so it turned the appropriate color. You could set it up such
that you have a rule and state the rule should turn a specifiec icon
a colo, or you could explicitly state that this event should turn this icon
a color.
Example of syntax:
verb: ASSIGN TARGET
entity: DOMAIN <name>
arguments: event source= <class> <instance> !defines who generates
the event
event name = "name"
managed object ="class #1" !**more later
target severity = value
target entity = "class #2"
** the regating allows for symbol substitution (#1), for up to 10 symbols.
These allow the user to state that the instance specified in this entity class, it so be used as the
instance value in the target entity value.
For your example it sdeems that something like this might work:
instead of a rule for...
(occurs(node4 router1 circuit ethernet adjacent node * adjacency down))
assign target domain name -
event source=node4 router1 circuit ethernet adjacent node * , -
event name = "adjancy down", -
managed objec="node4 router1 circuit ethernet adjancet node #1", -
taregt entity="node4 #1"
target seveiryt= major
What do you think? Do you see any other potential uses? I am trying to gather a list of potentially
useful examples that we could ship with the kit (v1.2).
jill
|