[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
|
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
1211.0. "AI based alarm interface (wish list)" by CLARID::PATEL (We'll get it right on the night) Thu Jul 04 1991 04:55
To Eng. This is indeed a wish list -- any comments very welcome
I'm not sure if this has been discussed anywhere, I looked through
(dir/key=alarm) -- no joy, here goes.
In the delivery of Managed Network services, we (Digital Services) are
planning on the use of MCC. The following applies for the current
platform we use today, but we have had a lot of feedback to work a AI
based alarm filtering mechanism.
What is being requested -- "A notification interface which takes
messages resulting from any alarm rule firing, and depending on the
topology relation for the triggered alarm pass it onto the output side,
which for us would be say MAIL".
IE, we have alarm rules set up to trigger if any of the nodes on the
other side of the bridge become unreachable, or if the Bridge it self
becomes unreachable. When any of these alarms trigger we send a mail to
a special address that results in a Service Call being logged in
Digital. Now, the job of the interface would be to ensure that if the
Bridge is in an unreachable state then NO POINT IN LOGGING SERVICE
CALLS FOR ANY OF THE NODES ON THE OTHER SIDE OF THE BRIDGE, remember
that once the bridge goes down very soon after MCC will realize that
the nodes are no longer reachable.
The point here is that products are being developed (almost in FCS)
which will validate the LAN ELAN topology, we could use the rule base in
that product to determine some of the rule bases for this interface.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1211.1 | sounds useful | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Fri Jul 12 1991 10:51 | 9 |
| I like it, well most of it anyway, and I can see the power behind what
you are looking for. As it is now V1.2 developement is well along in
the cycle and no new items are being considered for inclusion, but
items for future releases are always welcome.
Personally one of the things that I think would be real powerful is to
allow alarms action procedure to be an MCC command file and to take direct
managment action on the entity for which the rule fired... Keep the good
ideas coming.
|
| 1211.2 | We have the power | TOOK::ORENSTEIN | | Fri Jul 12 1991 11:09 | 18 |
|
With the V1.1 Ultrix version, you may have some of the power available
to you already.
Jill pointed out that she would like to see the alarms action procedure
be an MCC command file. Since it is a script file (or DCL on VMS),
it is simple enough to have the script invoke MCC to take direct
management action on the entity. Having the action procedure be a script
file provides much more power than an MCC command procedure could.
Now lets say you have rules on many nodes and on a bridge. You said
that when the bridge goes down you won't need to see the notifications
from the nodes. Simply write a shell script to invoke MCC and disable
the rules on nodes that you don't want to hear from. When the bridge
rule fires, use this shell script. The power is available, it's just not
automatic.
aud...
|
| 1211.3 | kind of | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Fri Jul 12 1991 12:26 | 7 |
| Audrey, i understand the potential of making a com or script file call
back into mcc, but I am looking for direct action within the same
instance of mcc. As you pointed out some of this will happen in the
ultrix world due to the differences in execution models, but in VMS
each mcc runs as a seperate instance and due to limitations in the system
that means that my mcc com file (on VMS) can disable the rule that just
fired because the rule is running in a different process....
|