| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1565.1 | | CCIIS1::ROGGEBAND | _ �hili��e _ | Tue Oct 01 1991 10:45 | 8 |
| Adrie,
If I remember correctly, when you run the TARGET_ENTITY.COM, you
already *know* that the entity is unreachable, so what you really want
is a condition which is always true, regardless of wether the entity is
reachable or not ? If so, you could try testing a reference attribute?
Philippe.
|
| 1565.2 | true or false | JETSAM::WOODCOCK | | Tue Oct 01 1991 16:45 | 23 |
| Hi there,
> If I remember correctly, when you run the TARGET_ENTITY.COM, you
> already *know* that the entity is unreachable, so what you really want
> is a condition which is always true, regardless of wether the entity is
> reachable or not ? If so, you could try testing a reference attribute?
If you are looking for a TRUE statement then a reference attribute is a good
idea to try. Theory says this would work but I've never tried it. But I would
like to point out one *feature* of using a false statement even though control
of severity is lost. When a server based router goes down it very often
requests a reload immediately. The reload process often takes less time
(1 min ??) than the event to be sent to MCC, target_entity to be submitted, and
the second TARGET rule to be created/enabled/and poll. Therefore when the
TARGET_ENTITY alarm polls the router it's back up and you get no alarm on a
"bounced" entity other than the original alarm. This sort of thing happens
from time to time and I appreciate the fact we don't have to chase down some
of these self fixing network realities. I guess it depends on where your
priorities and net mngmt practices are, and pick which method suits your needs
best (TRUE or FALSE).
best regards,
brad...
|
| 1565.3 | Becareful | TOOK::ORENSTEIN | | Tue Oct 01 1991 17:30 | 17 |
| >>> If you are looking for a TRUE statement then a reference attribute is a good
>>> idea to try. Theory says this would work but I've never tried it.
We have a problem with command procedure notification when REFERENCE
attributes are used in expressions.
YES you can write a rule on a reference attribute.
YES the rule will run properly and will fire appropriately
BUT we have a shortcoming in the command procedures.
It seems as if the quotes around the reference attributes are not
stripped from the data, so the DCL parameters to the procedure get
messed up. Sorry I can't tell you more than that. It is QARed but
is not scheduled to be fixed yet. We'll do what we can.
aud...
|
| 1565.4 | it works with reference attribute | HOO78C::TIMMERMANS | | Wed Oct 02 1991 17:32 | 37 |
| Thanks, the following works fine for alarm rule always TRUE:
------------------------------------------------------------
MCC SET NODE4 .'nodename' REMARKS = "UNREACHABLE", IN DOMAIN 'domain'
MCC CREATE MCC 0 ALARMS RULE test_'nodename' -
EXPRESSION=(NODE4 .'nodename' REMARKS = "UNREACHABLE")
PROCEDURE=MYPROC.COM, IN DOMAIN 'domain'
And the same for always FALSE:
------------------------------
MCC SET NODE4 .'nodename' REMARKS = "UNREACHABLE", IN DOMAIN 'domain'
MCC CREATE MCC 0 ALARMS RULE test_'nodename' -
EXPRESSION=(NODE4 .'nodename' REMARKS <> "UNREACHABLE"),-
PROCEDURE=MYPROC.COM, IN DOMAIN 'domain'
It only seems to give problems with the TEXT FILE attribute, which seems
to be unsupported.
This is usable if you want to known if an unreachable alarm is already been
fired without getting exceptions in your alarm procedure.
But is there a way to avoid the exception notification. Or adjust it's severity
level??
Because I have setup my rules in categories such as unreachable and reachable
rules,resource error rules and hardware error rules.
So at the moment if I get an unreachable alarm, I known the node is unreachable
at that time I don't want to have all exception alarms on my other rules for
this entity. Because if I don't reset those exception alarms every time I never
see that the node is reachable again.
Is the only way to avoid this by disabling all rules for this node, except for
the reachable rules???
Adrie
|