[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

4841.0. "Confused by alarms and notification" by CGOOA::DOLMAN (John of all trades - master of none) Wed Apr 07 1993 23:06

I have been trying to set up DECmcc on a customer site and have come across
some very puzzling problems that I cannot find answers to in the documentation.
How some things are done in DECmcc is quite confusing to me but I am sure there
is a good reason for it ... perhaps I am just missing something.

1) How can I set up my alarms so that all of the alarms that I have created
in all of my domains become ENABLED as soon as I run DECmcc (Iconic map)?

2)What is the best way to set up an alarm to test the availabilityof a station?
What I have done so far is set up an alarm that just tests to see some static 
attribute has changed on the station. If the station cannot be reached, then
the alarm has an exception. If the station can be reached then rule never fires.
This works but it seems rather hokey! Is there a more elegant way?

3)When I create a notification, I seem to be able to do so for the top level
domain in my domain hierarchy and have it propagate down to the sub-domains.
Can I define a target the same way. It seems that I need to define a target
for each domain that has the specified class of entities in it. This seems 
inconsistent as there is a direct correlation between notifications and targets.

4) Why are notifications, alarms and targets all stored so differently? 
Notifications need to be saved into a command procedure, alarms are stored as
entities in the MIR (I think), and targets just seem to magically reappear when
I re-enter DECmcc without me having to do a thing. I'm confused!!

5) Finally, how can I identify on a map, which bridge (in a spanning tree
configuration) is the one that is working. I can create an alarm but once it
is dismissed the map shows nothing. What is the normal way of handling this
situation.


Please excuse my ignorance on this product. I have not been able to work with
it enough to get truly comfortable with the underlying concepts. I am running
this on a VMS V5.5-2 system and using DECmcc V1.3 BMS.


				Confused in Canada,

					John Dolman
T.RTitleUserPersonal
Name
DateLines
4841.1TOOK::MCPHERSONpre-retinal integrationThu Apr 08 1993 14:3570
>1) How can I set up my alarms so that all of the alarms that I have created
>in all of my domains become ENABLED as soon as I run DECmcc (Iconic map)?

    You can't.  You have to got to the ALARMS view when you start, select
    all the rules, then hit "Enable" for ALL.  So it's still a 3-step, UN
    automated process. Sorry.

    This is a limitation we have with the IMPM right now and it
    has been brought to our attention on several occasions.   I *believe*
    that the people who complained about it did the right thing and put an
    entry in the NOTED::EMF_REQ conference so that it got duly noted (pun
    unintentional).

>2)What is the best way to set up an alarm to test the availabilityof a station?
>What I have done so far is set up an alarm that just tests to see some static 
>attribute has changed on the station. If the station cannot be reached, then
>the alarm has an exception. If the station can be reached then rule never fires.
>This works but it seems rather hokey! Is there a more elegant way?

    Hokey yeah, but about all that you can do for now, given a couple of
    limitations:
    	1. The Alarms FM can only alarm on ATTRIBUTE values
    	2. The Station AM (although it has a loop-back test command: LOOP)
           doesn't have a 'synthesized attribute' (call it "MAC-level
           Reachability" for now) that allows you to create an alarm rule to
           determine availability.

            i.e. EXPRESSION(STATION * MAC Reachability "DOWN")

           There is precedent for creating such a reachability attribute:
           the SNMP AM fabricates an attribute called "IP Reachability" (Up
           or Down).  [This is certainly *not* a standard MIB II variable. 
           What's the logic in asking a system "Are you up?"  When will it
           say "No,"?]  The SNMP implements the 'synthesized attribute by
           issuing a couple of ICMP echo requests to the SNMP host.  If it
           answers, then IP Reachability = UP, if it times out, then IP
           Reachability = Down.


>3)When I create a notification, I seem to be able to do so for the top level
>domain in my domain hierarchy and have it propagate down to the sub-domains.
>Can I define a target the same way. 

>4) Why are notifications, alarms and targets all stored so differently? 
>Notifications need to be saved into a command procedure, alarms are stored as
>entities in the MIR (I think), and targets just seem to magically reappear when
>I re-enter DECmcc without me having to do a thing. I'm confused!!

    Dunno on either of thses. Maybe someone that's worked on NOtification
    services will pipe up for this one.   Maybe there's some wisdom in the
    Alarms and Notification Servioces Use Manual about these topics.  Did
    you look there?

>5) Finally, how can I identify on a map, which bridge (in a spanning tree
>configuration) is the one that is working. I can create an alarm but once it
>is dismissed the map shows nothing. What is the normal way of handling this
>situation.

    I don't understand exactly what your problem is. What is it that you
    *expect* to see?  Do you want the map to be automatically redrawn if a
    bridge dies and your spanning tree reconfigures?   

>Please excuse my ignorance on this product. I have not been able to work with
>it enough to get truly comfortable with the underlying concepts. 

    From what I read here, I would argue that you seem to have a handle on
    the concepts, it's the *limitations* that you don't yet understand...
    ;^)

    /doug
4841.2look at MCC-REACHWELLIN::MCCALLUMFri Apr 16 1993 05:407
    
    MCC_REACH in note 24 of MCC-TOOLS conference discusses mcc and status
    polling in some detail
    
    Rgds,
    Dave