Conference azur::mcc

    I've seen that happen a few times on VMS only.  The problem on VMS is
    that alarms runs PER PROCESS, but generates events visible throughout
    the system.  For example if User-A is monitoring notifications which is
    picking up events from alarms,  and User-B and User-C are both running
    the same alarm rule, when the rule fires, two events are posted, one
    for each process.  User-A usually sees two notifications.
    
    -Matt.

  If you situation isn't like what Matt described in the previous reply;
  that is, you have multiple MCC's running on the system evaluating the
  same OCCURS rule -- then ...

  When you enable an Occurs Rule, Alarms asks the event manager for
  the specific entity event with a long duration (200 days).  For each
  event returned - alarms generates the 'osi rule fired' event.  The
  OSI event is picked up by the Notification FM/PM and highlights the Map
  by changing the Icon Color.

  I can only imagine that if you are seeing the same event multiple times,
  then it was put into the event manager multiple times...

    (Q) Are all the time stamps identical between the multiple Rule Firings ?

  You should try running an FCL window and issue the same directive which
  Alarms uses to get the event information .. example:

    Expression:  (occurs(node4 foo counter zeroed))

    Directive:   getevent node4 foo counter zeroed, for duration 01:00:00

  Enable the rule, and issue the getevent directive...then cause the event
  to occur -- in this particular example the directive to zero the counters
  is:  zero node4 foo

  -------------

  For your *proper* test -- use the rule which you are having problems with
  and the appropriate getevent directive .. and please let us know how it goes.

  /keith

Keith,

I just recogniced that Dave Comfort (who doesn't get answers from doug) entered 
nearly the same questions in note 2758. I have x25 routers and DECnetrouters 
mixed (DEMSAs), too. Like Dave. The times the Event and the message comes are 
not the same, but close together.

Example (our rules make a reply to the screen)

OPCOM message from event 4.17, area reachability change at 06:53:13.35

Reply 1 Alarm occured in Alarm rule AREA_REACH_CH at 06:53:13.92

Reply 1 Alarm occured in Alarm rule AREA_REACH_CH at 06:53:15.17


It seems the same problem to me like Dave described in note 2758.


Roland 

RE: .3

  Roland,

> OPCOM message from event 4.17, area reachability change at 06:53:13.35
> Reply 1 Alarm occured in Alarm rule AREA_REACH_CH at 06:53:13.92
> Reply 1 Alarm occured in Alarm rule AREA_REACH_CH at 06:53:15.17

  Whereas the Alarms occured 2 seconds apart, it makes me think that the
  DNA4 Event sync put declared two events...but...

  Could you try enabling the rule .. AND .. do a getevent directive? and
  post the output (using your specific event ofcourse)

  thanks -- Keith

> RE: .2
>
>  You should try running an FCL window and issue the same directive which
>  Alarms uses to get the event information .. example:
>
>    Expression:  (occurs(node4 foo counter zeroed))
>
>    Directive:   getevent node4 foo counter zeroed, for duration 01:00:00

    If it is caused by the same alarm rule running in another process, then
    you will aways get exactly two messages, one from each process.  Since
    it appears from Dave's note 2758 that it varies, then I would be
    inclined to agree with Keith.  That in fact, there are multiple Putters
    for the same Event.  (Why didn't we put UIDs on the events, anyway?)
    
    In any case, you could probably figure out how many alarms processes
    you have running simply by doing a show device/file and looking for
    how many processes are accessing the alarms mir files.  I don't know
    of any way of determining how many of the same rule you have enabled.
    
    -Matt.

I think I have also seen this happening. I had attributed it to DECnet
failing before but maybe not. I have similar symptoms at times (not readily
reproducible) where I recieve "circuit down circuit fault" events in the
notification window multiple times for the same entity without a "circuit up" 
event between them. One tidbit of info that is different is that I am not 
using ALARMS but strictly two notify commands (one for each event). I'll have
to start OPCOM and try to keep a running comparison to verify it is actually
an MCC problem.

best regards,
brad...

We have only one backgroundprocess that enables the alarms. So it's not like 
written in Re.1.
Now we will do a getevent like Keith asked for in RE.4. But we see the 
behavior only from time to time and not on every event. like Brad in RE.6.

We habe en Procedure that writes the alarm into a logfile. I will post what we 
see with the getevent.

Roland

  We have an internal problem which caused an Alarm event to occur twice
  through the notification fm/pm.

  There was *two* "enable domain <foo>" enabled for notification.

  This caused the single alarm event to occur twice in the notification window.
  Please check which notifications are enabled.

  /keith

    I am having similar problems as reported here and in 2758 with a DECmcc 
    v1.1, at a customer site DECmcc is set to monitor two areas in the same
    LAN, by listening to Adjacency Up/Down events. One router per area sinks 
    events to DECmcc.
    
    What happens is that Ajacency down is reported correctly, but Adjacency
    Up isn't. DECmcc generates the appropriate event as seen by the correct
    router,  but in addition just after  (but time stamped at same time) it
    generates  an event  saying that  the other area router saw the node go
    down.
    
    There is no doubt that is was DECmcc that did this, I looked at the
    OPCOM messages. And only one Down event arrived followed later by one 
    Up event.
    
    I have attached extracts from the command file logs, showing this.
    
    
    Gil
    
    P.S.  Another problem was that the command files pointed at by the
    rules created by the  re-targetting command procedure would not be
    invoked around half the time !!!  The Iconic map did change colors.
    
    
    
******************************
ETTS$DEVICE:[ANDRADE.GIL.MCC.TQ.T2]TARGET_TQ.D1;3056

$ @$1$DIA1:[MCC.ALARMS2]TARGET_TQ.COM;5 "MCC 0 ALARMS RULE JAM_CIRCUIT_ISA-0__DOWN"-          !rulename
"Node reachability event collector rule"-          !category
""-          !description
"(occurs(NODE4 JAM CIRCUIT ISA-0  		adjacent node * adjacency down))"-          !expression
"30-APR-1992 17:28:52.04"-          !time
"Node4 11.10 Circuit ISA-0 Adjacent Node 11.5 Adjacency Down has occurred 30-APR-1992 17:28:51.65"-          !dtcrtf or error
"NET1::NAM,jam::operateur,vega::operateur"-         !notification params
"SYS$SCRATCH:MCC_ALARMS_DATA_17285204.DAT"    !file that contains more info about the rule
    
******************************
ETTS$DEVICE:[ANDRADE.GIL.MCC.TQ.T2]TARGET_TQ.U1;3059

$ @$1$DIA1:[MCC.ALARMS2]TARGET_TQ.COM;5 "MCC 0 ALARMS RULE JAM_CIRCUIT_ISA-0__UP"-          !rulename
"Node reachability event collector rule"-          !category
""-          !description
"(occurs(NODE4 JAM CIRCUIT ISA-0  		adjacent node * adjacency up))"-          !expression
"30-APR-1992 17:30:50.42"-          !time
"Node4 11.10 Circuit ISA-0 Adjacent Node 11.5 Adjacency up has occurred 
        *>*>*>*> 	30-APR-1992 17:30:50.25"-          !dtcrtf or error
"NET1::NAM,jam::operateur,vega::operateur"-         !notification params
"SYS$SCRATCH:MCC_ALARMS_DATA_17305042.DAT"    !file that contains more info about the rule
    
******************************
ETTS$DEVICE:[ANDRADE.GIL.MCC.TQ.T2]TARGET_TQ.D2;3060

$ @$1$DIA1:[MCC.ALARMS2]TARGET_TQ.COM;5 "MCC 0 ALARMS RULE VEGA_CIRCUIT_BNA-0__DOWN"-          !rulename
"Node reachability event collector rule"-          !category
""-          !description
"(occurs(NODE4 VEGA CIRCUIT BNA-0  		adjacent node * adjacency down))"-          !expression
"30-APR-1992 17:30:51.42"-          !time
"Node4 11.10 Circuit ISA-0 Adjacent Node 11.5 Adjacency Down has occurred 
    	*>*>*>*> 	30-APR-1992 17:30:50.25"-          !dtcrtf or error
"NET1::NAM,jam::operateur,vega::operateur"-         !notification params
"SYS$SCRATCH:MCC_ALARMS_DATA_17305142.DAT"    !file that contains more info about the rule

    the adjancency up was not being returned inside of mcc with
    the correct code.
    
    fixed in v1.2