Conference azur::mcc

RE: .0

Steve:

  I can't solve this problem right now, but I just wanted to let you know that
  similar problems to this have already been filed in the NACQAR MCC_INT 
  database (QAR #77).

  I will be meeting soon with Jim Carey to see what can be done about your
  problem.  Alarms v1.0 does not support compound expressions (OR), but there
  should be other possible solutions.

  I will keep you posted.

                                                                     - Jerry

  P.S. Let us worry about this problem!  Our whole life is MCC!!  ;)
       At least that is what my boss tells me...  ;)

    
    Steve:
    
    Jerry and I have discussed this problem, and some similar problems with
    MCC and "simple" Phase IV alarming.
    
    We're doing the following:
    
    	Circuits will always have a substate.  That is, whenever you
    	request Circuit status, one of the attributes that will come back
    	will be the substate.
    
    If the circuit is in its normal ON state (when no substate is usually
    returned), the substate will be shown as "None".
    When the Circuit is OFF, the substate will likewise be "None" and if
    the circuit is in service state, the substate will be "none" unless the
    circuit reports itself to be in one of the defined substates.
    
    This way, normal circuit transitions can be tracked using MCC alarms.
    My take is this (and I may not have covered everything, let me know):
    
    In general, a DECnet circuit is in state ON.  If it gets into trouble,
    a node on the other end crashes, or hardware transients start to effect
    it, then the substate will start to flucuate, and that is interesting
    information to alarm .  For example, it might go to ON-synchronizing,
    and you would likely want to alarm on that.  With a permanent,
    guaranteed substate, that it easy.  My impression is that as long as
    you can expect a substate to be returned (even none), then the STATE
    attribute isn't terribly important.  You want to know when the substate
    changes and that is probably enough information to set up a reliable
    alarm or condition handler.
    
    For the circuit state to change generally requires operator
    intervention.  This is a different problem, and should probably be 
    driven off of a separate alarm.
    
    Jerry can give you some more information about Alarms themselves, I'm
    only playing with the Phase IV AM so far.  The Alarms team has changed
    some subtle rules defining how and when rules fire or disable, and has
    added some exception handling capabilities to the rule definition stuff
    somehow.  This will be available with EFT update, as will the
    garuanteed return of the circuit substate.
    
    Jerry will also know more about what our plans are for conditional
    support in alarm rules.
    
    Finally, I've been working with DECnet Phase IV for a long time but
    don't pretend to know all of the interesting relationships of all of
    the attributes.  If you feel that State and Substate really can't be
    considered separately, let's get the exact scenario mapped out and see
    if we can't come up with two kinds of solution:
    
    	- one that'll get what you want with V1 of MCC.
    
    	- and one that'll provide a simple answer that we can integrate
    	  down the road.
    
    If we can collect and understand specific management requirements, we
    can often move to meet them quickly.
    
    Hope this helps.
    
    -Jim Carey. DECnet Phase 4 AM
    

Thanks Jim for your response. The solution of using "None" for substate will 
help alot. But...

I will still need to alarm on BOTH substate and state for circuits. In our case
ACTnet is a WAN network and although we manage the backbone centrally,
local sites  (20 +) do have operator control of their WAN routers. -Sounds a lot
like Easyent! Therefore, we need to detect if someone turns off a circuit. 

Another example that shows how circuit state & substate are "related" is
how the current NMCC DECnet monitor treats them. I believe that the line graphic
display turns from Green to Red for either occurance (state or substate change).

So the current answer is to double the number of alarms rules to monitor circuit
"status"; As the number of alarms rules grow so does my concern about my ability
to manage them!

Thanks for your attention ==Steve

RE: .3

  Sorry that I haven't responded to this earlier.

> So the current answer is to double the number of alarms rules to monitor 
> circuit "status"; As the number of alarms rules grow so does my concern 
> about my ability to manage them!

  I agree with your analysis.  We are certainly very aware that we don't want
  to make the management of Alarms more difficult than the management of the
  network!

  Compound alarm expressions are certainly a good start to lessening this 
  problem.  In addition, wildcard support, and rule "sets" (groups of rules
  that can be enabled and disabled together) are two other features that are 
  in our future plans.

  For now though, please bear with us by utilizing command procedure for 
  CREATing and ENABLing rules.  More is coming... :)

                                                                     - Jerry

    

    
>>> Another example that shows how circuit state & substate are "related" is
>>> how the current NMCC DECnet monitor treats them. I believe that the line 
>>> graphic display turns from Green to Red for either occurance (state or 
>>> substate change).

    Is there any plan to incorporate some means of changing the colour of an 
    icon in a map should a certain alarm condition be true.  (e.g.  If a node
    changes state from 'reachable' to 'unreachable' will it be possible to 
    have the icon for the node change colour?)
    
    
    

    Yes, we are planning to support icon color changes when a rule fires. 
    The color is dependent on the severity of the alarm, and will be user
    customizable.
    
    This is planned for V1.1.
    
    Christine
    

    Unless we're planning to require color workstations, then will we (I
    hope) also make it work such that it will be visible on a monochrome
    system?

    The following opinion is the result of the -AND- operator being
    applied to my view and the view expressed by more than one potential
    customer:  The status of network devices must be represented on
    the map in near real-time or the map ( -AND- DECmcc) will not be
    used as part of my network management solution.
    
    Regards,
    
    Glen R.
    

    We would be interested in your feedback after you have had an
    opportunity to play with the EFT kit, due out shortly. This kit
    will be the first publicly available kit with notification support
    (what you refer to as the color changes) from both the iconic map
    and FCL PM.
    
    jill