Conference azur::mcc

    ,
    
    With only 32MB I suspect that you will not be able to run many alarm
    rules due to memeory problems. If possible you might think about 
    using the data collector which should be more efficient.
    
    I suspect that I have seen ( but cant believe its true) icons
    being updated in the wrong order when generating several icon
    changes on a heavily loaded system (not loaded by DECmcc).
    
    Could engineering also confirm that icons are always updated in the
    correct order when several events happen in a short period.

>    With only 32MB I suspect that you will not be able to run many alarm
>    rules due to memeory problems. If possible you might think about 
>    using the data collector which should be more efficient.

"memory problems" ?  The alarms FM is fixing several issues right now; one of
those is memory.  

I don't understand the reasoning behind your "suspicion". It's not clear to me
how the Data Collector AM buys you anything, either.

Why enable an alarm rule for *every* event ?  If you must have alarm rules,
then why not why not one per class with "Any event" specified ?

>    I suspect that I have seen ( but cant believe its true) icons
>    being updated in the wrong order when generating several icon
>    changes on a heavily loaded system (not loaded by DECmcc).

Differences would mostly likely be between CLASSes as opposed to instances of a
the same class.

I would expect that this would be dependent on the complexity of EVENT support
by *each* particular AM.   I.e. AMs with simpler GETevent support may return
faster to Notfication Services faster than a 'near simultaneous' event from a
more complex beast (say something with a big OSI Event report...)

Re .2
    
>   Why enable an alarm rule for *every* event ?  If you must have alarm rules,
>   then why not why not one per class with "Any event" specified ?
    
    This might be a good idea, but in some cases we have to create specific
    alarm rules for every single event. 
    I gave the assumptions in .0 in order to simplify the calculation.
    I still looking forward to receiving some estimate. If we will compete,
    we have to deliver them.
    
    Regards Ulf

>    This might be a good idea, but in some cases we have to create specific
>    alarm rules for every single event. 

Still, would you mind sharing specifically *why* you must have an alarm rule
created for each event?     The better you can explain your requirement(s) the
more likely that we can provide alternatives, if the alarm rule creation gets
too expensive.

.doug

I'm not sure about base note but if we alarm on different events it is most
likely the events would have different severities. Circuit up/down events
are the best example. It is also good to use multiple severities if many
events are being alarmed to help with the graphics on the monitor for a
better understanding of what is going on.

kind regards,
brad...

    I thought the data collector would be a better choice as 
    
    1. I supposed it would not use CPU power even when no events occur.
       Alarms rules do. 
       - is this not the case for data collector
    2. I supposed it cannot use 100 Kb memory for each alarm rule.
       Is the data collector heavy on memory use too ?
       
    3. You need a lot of alarm rules as all the data in an alarm rule
       has to be hard coded.  It would have been useful to be able to
       specify parameters (calculated at run time) in the alarm rule.
       The data collector does allow parameters to be calculated at run
       time.
    
    4. Does wildcarding for global entities not have to be implemented in
       the AM as well as the alarms FM. 
    
       Using expression 
       EXPRESSION          = (OCCURS(entity * NODE OTHER)), -
       I get the following message :
    
       "Unsupported wildcard in target entity specification" 
    
       when I wild card the entity name. Is this an AM FM or my problem.
       If it is AM dependent I suggest the documentation is updated
       too reflect this.
    
     Regards,
    Jeremy
    
    
    
    
    

Yes, the Data Collector is a 'light-weight' way to achieves some things
cheaply, BUT you get what you pay for...

The Data Collector AM is nothing more than an event sink that only listens for
ONE EVENT: "General Event".  That's all it knows how to do.    It has virtually
zero "intelligence" compared to Alarm Rules or other (more sophisticated) AM's
event processing and     

Notification Svcs does a lot of 'fancy stuff' behind your back to help out the
Data Collector and make it more usable, like substituting the event reply text
(aka event 'title' in the API 'send' code) for the event name. 

Also, since the Data Collector AM is only really receiving ONE type of event
(General Event) you can only create ONE OCCURS alarm rule.   The Alarms FM 
requires the ACTUAL event name, *not* the text that Notification Svcs is
slipping in there for you...

regards, 
doug

RE: .6

  Jeremy,

>    4. Does wildcarding for global entities not have to be implemented in
>       the AM as well as the alarms FM. 
>    
>       Using expression 
>       EXPRESSION          = (OCCURS(entity * NODE OTHER)), -
>       I get the following message :
>    
>       "Unsupported wildcard in target entity specification" 
>    
>       when I wild card the entity name. Is this an AM FM or my problem.
>       If it is AM dependent I suggest the documentation is updated
>       too reflect this.

  Because the Event Manager *can* process Global Wildcards, the MM does
  not need to do anything special for its GETEVENT directive.  In your
  example (above), which MM were you using - that returned the 'Unsupported
  wildcard...' error to Alarms?

  /keith
  

    I the MM is an AM that was developed in Annecy -
    apparently it is the AM that does not support wildcarding -iisue being
    worked.
    
    Regards,
    jeremy

>    I the MM is an AM that was developed in Annecy -
>    apparently it is the AM that does not support wildcarding -iisue being
>    worked.

  I imagine that the AM is based on the DECmcc Toolkit Design Framework.
  Well, at least I hope it is  8)

  What you need to do is make a changed to the Call Argument Validation
  Table for the GetEvent Directive .. such as this code-segment from the
  Toolkit Example FM's GetEvent Directive:


  static  dt_valid_in_entity_args  valid_in_entity_args[] = {
    MCC_K_CLASS_SAMPLE,     CAV_V_INST_FULL_WILDCARD, MCC_K_DT_PHASE4NAME,
    CAV_K_RECORD_SEPARATOR, CAV_K_END_ENTITY_COMB,    CAV_K_RECORD_SEPARATOR
  }


  The second argument in the table says what type of instance is allowed
  for the Entity .. Your AM probably says CAV_V_INST_NO_WILDCARD now.


  /keith

    Since everyone else seems to be side stepping the question.
    Here is a guesstimate (using v1.1) to the original question:
    
    How many events per second can DECmcc handle ?
    
    The answer "less then one", and if it receives more it gets behind the
    event stream and starts firing rules, saying the event happened to "*"
    wich is not very usefull.
    
    Events like everything else in DECmcc are done slowly, and you don't
    want to use them for things that happen many times per second.
    
    Gil

    actually based on the latest numbers, it looks like through
    the FCL we can handle between 5 and 8 events per second 
    at a steady rate without getting left behind. In the
    cases of bursts it will take the appropriate amount of time
    to catch (#in burst divided by 5 approximates catch up if
    no new events coming in). And yes this is up significantly from
    previous baselevels, and hopefully will be going up more still.
    
    jill