Conference azur::mcc

    just a stab in the dark....

    if you show all counters for a line the "collision detect check
    failure" counter text reads ....

    Collision Detect Failure, may be that's what needs to be in the
    expression text instead of "COLLISION DETECT CHECK FAILED>20, "

    ie miss out the "CHECK"

    You're correct; however, the MCC GETEVENT command returns a different
    description "COLLISION DETECT CHECK FAILED".  I was getting a "syntax"
    error before I changed to this ^ syntax.
    
    Thanks for the suggestion, though.
    

>     EXPRESSION = (NODE4 MYNODE LINE QNA-0 COLLISION DETECT CHECK FAILED>20, -
>                   AT EVERY 00:05:00),-

You keep talking about GETEVENT (?!)

If you try to trigger on an event you have to specify:

EXPRESSION = (OCCURS(NODE4 MYNODE LINE QNA-0, COLLISION DETECT CHECK FAILED))

*Robert

    
    .1 or .3 would both work....
    
    In DECmcc V1.1 you can use an Alarms OCCURS function to recieve
    indication that an event occurred, or you can use the Alarm COMPARISON
    rule to monitor for example a particular counter.
    
    V1.2 Alarms contains an additional capability that can confuse this 
    situation even more!  I'm not sure of the exact syntax, but you will
    be able to specify that you want an alarm to "fire" only if it occurs
    a certain number of times in a short duration.
    
    For a comparison rule, that might mean that you want to check line
    utilization every ten minutes, and if it stays above 60% for three
    intervals, you want to know about it.  Something like that will allow
    you to damp out the peaks in network activity.
    
    I'm not sure if a similar thing will work for the OCCURS function, but
    if so, you could set up an OCCURS rule on an event, and say that you
    only want to hear about it if it occurs more than 10 times in five
    minutes.
    
    Just for my edification:  Is CDCF a valuable thing to monitor?  I
    worked with some Ethernet hardware years ago and CDCF was something we
    learned to ignore.  It seemed a lot of perfectly nominal Ethernet
    setups would report CDCFs left and right, even when everything was
    fine, and to keep from using up console paper (yep, THAT many years
    ago), we used to suppress them.  Has that changed so that this event
    (or counter) is worth watching?
    
    Just curious, and comments welcome.
    
    -Jim Carey
    

    For those of you who made the same mistake I did, here is the rule
    in a tested and workable format.  For additional info, look in the
    Master Index or Alarms FM Index for "EXPRESSION_RULE_FORMAT,
    COMPARISON_RULE_FORMAT, CHANGE_OF_RULE_FORMAT, and OCCURS_RULE_FORMAT. 
    Also, look up "Alarm Conditions, determining".  Note the differences. 
    OCCURS should be used for events.  GETEVENT command determines what
    events are allowed.  Others are for rules involving entity attributes,
    such as COUNTERS, STATUS, CHARACTERISTICS, ...
                    
    CREATE MCC 0 ALARMS RULE COLLISION_DETECT_FAILURE -
     EXPRESSION = (NODE4 mynode LINE QNA-0 COLLISION DETECT FAILURE > 20 ,-
                    AT EVERY 00:05:00) ,-
     PROCEDURE  = MCC_COMMON:MCC_ALARMS_MAIL_ALARM.COM ,-
     EXCEPTION HANDLER = MCC_COMMON:MCC_ALARMS_MAIL_EXCEPTION.COM ,-
     CATEGORY   = "Connection Problem"
     DESCRIPTION= "Line CDC failure.  Interface did not see heartbeat. -
                   Potentially bad tap, transceiver, cable, bulkhead,  -
                   interface, or connection to any of the above.  Also -
                   could mean Line is ON with LOOPBACK connector in    -
                   place."
     QUEUE      = ALARMS$BATCH ,-
     PARAMETER  = "MYNODE::NETMANAGER" ,-
     PERCEIVED SEVERITY= MINOR ,-
     IN DOMAIN  = .mydomain              

    Collision Detect Check Failure is indeed a valuable attribute to look
    at.  With some equipment, that does not work correctly (the DEMPR is
    one I believe) - occurances don't mean much, but with a correctly working
    network, one can sometimes find the 'bad guy' be searching a list of
    nodes to find out which ones are seeing CDCF.  A good algorithm would
    be 'if it happens all the time, ignore it, but if it hardly ever
    happens, when it does it is significant'.
    
    bill

Next time your trying to figure out the right name for an attribute
or an event...

from the FCL

MCC> use mode forms

Verb:  show		(or getevent)
entity: <the entity class * that you want the info on)
attr/arg: <PF2>

The PF@ key will give you context sensitive help specific to the location of
the cursor when the key is hit, and specific to the data currently filled in.
In this case if you filled in show node4 * circuit * you would find out the
list of valid attributes for the node4 circuit entity. If you change show 
to getevent, you would get the list of potential events.

One thing to keep in mind. The data returned with the PF2 key is what is
architected and supported by the AM, different devices may support different
subsets of these.

jill

     RE .4
    
    Thanks Jim for anwering while I was out.
    
    A slight clarification:
    
    The additional capability that Jim spoke of (for V1.2) for
    allowing the user to specify that he wants the alarm to "fire"
    only if an event occurs a certain number or times in a short
    duration, will only be present in the OCCURS RULE FORMAT.
    
    If an EVENT occurs so many times within a time period the rule
    will fire.
    
    aud...