Conference azur::mcc

    Yes or No. It really depends upon the customization. There are other
    ways to do things than what you described. Notification Services
    in the future will be extended to provide greater alarm notification
    functionality. But it is not clear that the extensions you describe
    is the direction they will go. I for one would not propose using
    color as the way to hold history about an alarm that has been cleared.
    From work I did in a previous lifetime (ie. Life before DEC), I know
    that alarms have many states. An alarm can be active, that is the
    conditions that triggered the alarm still exist. An alarm can be
    Inactive. An alarm can be Viewed, that is the intended operator
    has seen it and is aware of it. An alarm can be unviewed (if that
    word makes sense). I can have alarms which are active and viewed,
    active and unviewed, inactive and unviewed, inactive and viewed.
    Each user will have a different set of policies on how they want
    to do with alarms based upon these states. I would hope that
    we don't arbitrarily implement one policy (ie. you suggested a 
    policy that makes sense to you) at the expense of others. Note,
    that What I suggested is that an alarm may have multiple states
    with multiple values and that a policy needs to be aware of all
    the combination of states and values. When you get down to it,
    I have used 2 states in the example. There are additional states
    or values that I chose not to present to keep the example simple.
    For example, I could extend the first state by adding a value
    of archived or I could add an additional state of archived and
    have as its value true and/or false.
    
    wally

    re: .1
    
    I agree with your assessment in theory.  Customers want to be able to
    define the parameters of what alarms will do.  You use
    active-inactive-viewed-unviewed and the host of permutations derrived
    from that.  Being able to define a color for each state is an
    extention of the same idea.  This customer wants to be able to define
    a criteria for alarms and see that implemented on the iconic map.
    I would hope DECmcc will offer that kind of flexibility.
    
    Joe

       I have installed and demoed DECmcc for my customer and they love it !
    
    They would like to provide it as a tool for their operations staff.
    The question they have is how hard is it to customize the actions
    taken on the iconic map.
    
    For example, I can define a rule and when that rule fires, there is a
    color change on the icon for which the rule was defined.  Once I select
    that icon I can look at the alarm and clear it.  What if I
    want to keep track of which entities have ever had an alarm whether it
    was cleared or not ?  I'd like to have another color that says
    "This entity had an alarm today and was cleared."  I guess what I am
    asking is can you modify DECmcc alarms so that entity goes from
    one state to another.  Instead of "on" or "off", you could have
    "in work", "completed", "deferred" and colors to go along with the
    state.
JLL>
JLL> I do not believe you are asking for Iconic Map customization but rather 
JLL> extending the Notification Services and Alarms FM existing functionality. 
JLL>
   
    The customer has other questions about customizing the window that
    comes up when you "display alarms".  They would like to see other
    information in that window.  They would also like that window to
    "pop-up" when the icon is selected.

JLL>
JLL> What other information does this customer want in the window?  Having
JLL> the window popup when the user selects something might please this 
JLL> customer but I know will annoy many others.  
JLL> 
    
    How customizable is DECmcc ??  What do I tell this customer ??
JLL>
JLL>  Take a look at the customize menu entries for both the map and management
JLL>  windows.  This will give you a feel for what can be taylored.  In
JLL>  V1.1 there isn't that much. V1.2 will note be any better.
JLL>

    Am I looking at writing a new PM ?
    
JLL> 
JLL> To answer this I need to know the interface requirements that the Iconic
JLL> Map does not meet.   If the total list is in your note, it may not be
JLL> worth the expense. 
JLL>

To me what you seem to be asking for is a trouble ticketing type of 
functionality. With trouble ticketing, you can keep track of the 
current state of an "occurrence" (where occurrence means a rule
or event triggering a color change on the map). In a trouble ticketing
environment you would be able to acknoledge a trouble ticket, as well
as clear them, and "manage" them. Unluckily this isn't being done in
our group, but efforts in this area are ongoing.

PNMP (Public Network Management Platform) might help you solve your problem. 
PNMP will be an application layered on top of DECmcc/Ultrix V1.2. The first 
version of PNMP will provide, amogst other things, alarm handling and trouble 
ticketting.  

Alarm handling will allow you to keep track of alarms and their states, while 
trouble ticketting will allow you to keep track of problems. 

For further information, please contact PNMP product manager Claude Hary 
(ULYSSE::HARY) or use the PNMP notefile TENERE::PNMP.

Best regards,

Marc.