[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2333.0. "Need more manageable alarm rules capability" by CUJO::HILL (Dan Hill-Net.Mgt.-Customer Resident) Thu Feb 13 1992 00:03

    In each domain, we have been using the name to organize/group certain
    alarm rules (e.g., BRIDGE_AA_MYBRIDGE1_BRIDGE_BROKEN) since everything is
    sorted alphabetically.
    
    How difficult would it be to provide a hierarchical management system
    for rules similar to that of a directory such that a double-click on a
    box labeled BRIDGE_AA would expand to show all alarm rules?
    
    EXAMPLE:
    
    BRIDGE_AA
    	MYBRIDGE1_BRIDGE_BROKEN
    	MYBRIDGE3_BRIDGE_BROKEN
    BRIDGE_AB
    NODE4_AA
    	NODE1_LINE_RECEIVE_ERRORS
    	NODE5_LINE_RECEIVE_ERRORS
    	NODE5_PIPELINE_QUOTA_LOW
    
    -Dan
T.RTitleUserPersonal
Name
DateLines
2333.1Navigation enhancements in IMPM needed...DFLAT::PLOUFFEJerryTue Feb 25 1992 14:0231
Dan:

  Good question.  I've thought alot about this kind of issue in the past.

  Today's version of the IMPM is restricted to navigating between entities 
  on the basis of the containment (parent-child) relationships inherent in
  the DECmcc product.  We can zoom into an entity to see its children and 
  we can look up from a child to see its parent.  After running the IMPM for
  just a few minutes you will be familiar with these operations.

  What we need to do in the future is to allow the user to navigate between 
  entities based on non-containment relationships.  The alarms example you 
  mentioned is one of the best examples of how we could use this new
  capability.

  The relationship between an alarm rule entity and another entity (node,
  bridge, etc.) is not parent-child.  I don't want to get into all of the
  technical reasons why this is so.  I like to call this relationship the
  "detects-faults-in" relationship because the alarm rule "detects-faults-in" 
  another entity.

  DECmcc needs to maintain and manipulate these kinds of relationships in 
  a USER_FRIENDLY way so that we can provide more powerful capabilities like
  what you have suggested.  A package like Hypercard is a good example of the 
  powerful user interface that is possible when this kind of capability is
  implemented.

  I hope we can provide this kind of capability in future versions of DECmcc.

                                                                     - Jerry