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 |
Hello, We are running Watchdog on VMS 5.5-2 and sending events to DECmcc v1.3 using mcc_evc_send. The problem is we are getting multiple notifications when a collector am is established in each domain. For example, I have two domains towson1 and towson2. If I established the same collector am in both domains, and send an event to an entity in towson1, I get two messages. The correct map icon changes color and the alarm propogates up to the proper domain. However, I get an event for each collector am that is created. Both icon maps change color. What I want to do is establish a single collector am in the top level domain and have it work for all entities and subdomains. Any suggestions? Please note that this problem is independent of Watchdog. Thanks! Becky, Jim and Scott
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
5060.1 | sorry, that's the way things work | MCC1::DITMARS | Pete | Tue Jun 08 1993 12:01 | 7 |
You either sprinkle one collector in many domains and deal with duplicate notifications or you put distinct collectors in different domains and put enough intelligence into the part that is generating the events to know which collector to send the event to. No clear winner of a choice. | |||||
5060.2 | common naming or mcc_reach??? | CTHQ::WOODCOCK | Wed Jun 09 1993 13:56 | 29 | |
Hi Becky, Jim and Scott Pete's answer is where it's at but let's take it further. The problem is to set up a different collector for each domain and *understand* the entities within each. That way you can send the event to the proper collector. You can take a couple of approaches. Given a node name if there is an easy way of identifying the domain from within the entity name you are all set. What I usually would recommend is naming the collector <domain>_collector. This is where naming schemes come in handy. For instance, all our routers are named BBLKnn from a particular site and all these routers are in a domain called lkg-55 (which is the site). So parsing on a portion of the router name (lk) allows the procedure to figure out what domain it's in and send the event. If you cannot set up naming like this than you'll need more brute force. Note 24 of NOTED::MCC-TOOLS points to a utility called MCC_REACH. It was built with a different need in mind but some of the procedures may work for you. One of these procedures will actually build an indexed file of all entities and corresponding domains for the given top level domain (and all sub-domains). This is run each night at midnight to keep relatively up to date with the config. The alarm procedures which fire simply read from the index file to determine the domain (and hence the collector) to send an event to. Note this was made for V1.2 and the send_event command does not contain the PROTOCOL. Just an idea, pull it apart if you know dcl and it may work well for your application. best regards, brad... | |||||
5060.3 | MCC_REACH works | 36905::DISNEY | Jim Disney, dtn 339-5753 | Tue Jun 22 1993 15:58 | 1 |
MCC_REACH does what I need. Thanks. |