Conference azur::mcc

    
    To use the events argument of the notify command you must also specify
    the entity list (previous version called the argument entities)
    argument as well. You may use global instance wildcards in this
    argument. The wildcards will be expanded within the context of the
    domain so as to set bounds around the list of entities for which
    the commands is actually waiting on events. Hope that makes sence.
    
    The new BMS use manual updates look great for describing alot more
    of this stuff. May be if you contact Joe O'Connor you can get  yourself
    an early copy to review.
    
    The main item to note regarding the entity list/event arguments
    is that the entity class used in the entity list is the class used
    in parsing the specific events/partitions passed on the event argument.
    
    NOTIFY DOMAIN X ENTITY LIST=(NODE4 GOSTE, NODE4 BOEHM), -
           EVENTS=(ANY CONFIGURATION)
    
    This doesn't answer all of your questions but I hope it helps.
    jill
    

Hi Rob,

>    In this case, is the entity the system that generates the event even if
>    the event is not related to that entity? For example, adjacency up/down
>    event is usually generated by a router even though the event is about a
>    different entity.
    
I'm in the middle of some prelim testing and this is what I've found so
far. The notifications I've received for adjacency down has been on the
entity which generated the event. The most useful place for this event
would be for node status on LANs. In this situation the wrong entity is
highlighted. I'm looking to stop proactive polling completely so I may
use this event to drive a com procedure to create/enable a temp alarm
to do a reactive dummy poll and use exception handling to highlight the
correct icon. It's only a thought right now, I haven't gotten far enough
to verify this concept yet because it's a messy solution and I need to write
the com procedure.

Another use for this event is for WAN connections. The event only tells you
that the node is no longer adjacent. This could be caused by a WAN circuit
outage. I'll probably use this event instead of "circuit down circuit fault"
because it gives more info. It would identify the node, circuit, and what
USED to be adjacent. This may help us keep our maps up to date. Although
I'd still rather have a LINE module to hightlight map lines for these
outages, but it seems the MCC santa didn't bring it this year.   
    
    
cheers,
brad

    
    Just to let you in on some futures for the Notification FM...
    
    We are planning on implementing what we call the "target entity",
    when a rule is created (an potentially this might instead be done
    on the enable, the jury is still out) a target entity can be optionally
    specified. In this case when the rule fires the notification FM
    will check to see if there is a target entity defined for the rule,
    and if so the target will be highlighted instead of the entity
    specified in the rule.
    
    We were hoping to get this into V1.1 but unluckily we didn't have
    the resources (it only made it as far as getting defined in the
    dictionary...).
    
    Thought you might be interested. If you feel you have, or would
    like to come up with, some requirements/wish list items for the
    Notification FM then I suggest you start a new note on the topic.
    
    jill
    

    Thanks all for the info.
    
    Hmmm, back to thinking about it again...
    
    s/rob

    
    We are planning on implementing what we call the "target entity",
    when a rule is created (an potentially this might instead be done
    on the enable, the jury is still out) a target entity can be optionally
    specified. In this case when the rule fires the notification FM
    will check to see if there is a target entity defined for the rule,
    and if so the target will be highlighted instead of the entity
    specified in the rule.
    
    We were hoping to get this into V1.1 but unluckily we didn't have
    the resources (it only made it as far as getting defined in the
    dictionary...).
    
> Your intuition on developing this feature will be appreciated as I
> believe it will be used quite often for important monitoring. Although
> I could use something in the very near future such as this. Since 
> development has already begun is there a time frame in mind (unofficial
> and uncommitted, of course) for completion. It would be helpful to know
> this timeframe because I may develop a solution for our own needs for
> the interim.

thanks,
brad...
    

    
    UNOFFICIALLY.....
    
    We want to get it into the 1.2 kit along with the ability to specify
    what action to take when a notification occurs. This would then
    allow actions to be taken internal to MCC based upon any event.
    
    The target entity would most likely be on the create, but the action
    would be specified on the notify command so that you wouldn't have
    to modify a rule to remove an action, simply halt and change the
    notify request (and each user of a rule could have a different action).
    
    

    Hi
    
    I am just catching up following some work I did for a large customer in
    Australia in March, and came across this note. If there is a better
    place to post this then please move it!
    
    If the 'jury is still out' on this idea of a target entity, or if there
    is any need for extra push to get this feature into V1.2 then please
    let us know. Based on the feedback from thie customer it is going to be
    an essential feature if we are to be able to set up MCC correctly for
    such customers.
    
    The customer was very pleased with the bits of MCC we were able to show
    them (it was not supposed to be an MCC demo - rather we were using MCC
    as past of a remedial excersice) and I am sure we can make big sales
    here. 
    
    However the inability at present to make the 'real' victim entity of
    some network fault change colour was seen as a big problem for them.
    
    What this customer wanted can be summarised as:
    
    	- to be able to show on the iconic map the 'real' victim of an
    	event or sequence of events, based on logic driven by the
    	triggering of an alarm
    
    	- to be able to display the state of the network _as_ _well_ as the
    	state of the alarms on the network.
    
    We found we had no trouble explaining to the network manager how alarms
    and the iconic map worked, and that the change of colour reflected the
    entity that detected an event and not necessarily the underlying
    problem. However as he pointed out this was not what his network
    operators wanted to see.
    
    His requirement is (a) to allow everyone so see the state of the
    network at a glance, and (b) for the operators to be notificed of
    events that require their action.
    
    In this customer's network, there was a mesh topology between 6-10 core
    nodes. We created rules that would be triggered by DECnet events from
    each of these core nodes when one of their circuits failed.
    
    This all worked fine - but as the customer showed, when one of these
    core nodes totally failed, then all the others would log an event
    ("Circuit down Circuit Fault") and change colour, whilst the one that
    was sick stayed GREEN. This is clearly crazy (reverse polish logic:-).
    
    Furthermore, they considered it rediculous that an operator could read
    an alarm from an entity and thereby turn its Colour back to GREEN
    despite the cause of the event being still present (for example the
    circuit/node is still down).
    
    What we appear to have here is a difference between an academic and
    real world. Its clear that once you understand the DECmcc way of doing
    things that its perfectly useable, but if you take the average network
    operator (who maybe having to handle a number of different network
    management interfaces from different vandors) then its not that simple
    to explain how we work.
    
    What would appear to me to be needed is two types of state change.
    Type 1 would be show that an alarm had been triggered and could be
    cleared by operator action. This type would not go from "Critical" to
    "Less than Critical" if two different events arriveed - it would only
    go from good to bad.
    
    Type 2 needs to be some state that can only be cleared by the arrival
    of another event. In this case "Good News" should be allowed to
    override "Bad News".
    
    For example, I would see this working as follows. 
    
    	- a circuit fails and the DECnet event for this failure causes
    	an alarm to be triggered.
    
    	- the entity that logged this event would change state (eg. minor
    	status)
    
    	- Part of the alarm rule would work out what the real cause was (ie
    	the node at the other end of the circuit has gone away) and force
    	it state to change to "suspect")
    
    	- An operator would be able to reset the "minor" state from the
    	node that logged the event when reading the event. However the only
    	way to get the "suspect" node out of this condition would be for 
    	its circuit to come UP and therefore the CIRCUIT_UP alarm from the
    	node thats logging all these events would be able to do this.
    
    If all of this is totally half-baked, then please say - but its based
    on not very much exposure to MCC, but considerable exposure to the real
    world, including real network management from an operational point of
    view (both personally and with other Digital customers). I feel we have
    a really good product here (its easy to impress customers with it
    initially) but once they start to dig then there are some features
    missing that they thing are 'obvious'! Clearly there are good reasons
    why we did not implement them, but its not always apparent!
    
    Its just a suggestion....
    
    Cheers for now
    
    Bob