Conference azur::mcc

    The IMPM and/or FCL (& mail) notification is automatic. With IMPM you
    then invoke a pop-up (MB2??) to display any alarms that have fired.
    regards,
    Jeff.
    

    Jeff,
    
    	If I understand your response, the customer would have to first
    determine that he/she had an alarm by detecting a color change on the map,
    or discover that mail had arrived, correct ? Then he/she would have to 
    press MB2 to get the pop-up window, is that correct ? What the customer 
    is looking for is a window to pop-up when the alarm occurs so that 
    constant map scanning is not required, or having to check for mail 
    periodically. Is this possible ?
    
    George
    

    Hi,
    
    as I know, it's not a "feature" of DECmcc but, of course, you can
    achieve this based on the "command procedure" mechanism.
    
    In fact, I did the same thing (only as a "demo") in a customer site. I
    modified the sample "mail sender" procedure to run a little program
    which displays a window requesting "acknowledge" of the alarm.
    
    This little program was an example included in DCM or TCW to give the
    same functionality you are requesting.
    
    The only problem could be that the "command procedure" runs in batch,
    and you must specify in it the name of the target display (using the
    command $define DECW$DISPLAY ...).
    
    I hope this help,
    regards.
    		Jos� Luis.

    Jose Luis,
    
    	Thanks for the information. That's the approach I had considered,
    but wasn't sure if it was already part of the IMPM. I'll use your
    suggestion. Thanks for taking time to reply.
    
    Best regards,
    George
    
    Note to developers:
    
    	The pop-up window alarm notification has been requested during two
    DECmcc demo situations. If it is not planned for the product, it should
    be, and should not have to be implemented as a command procedure
    initiated operation.
    
    Thanks,
    George

    Hi,
    
    RE: .2
    
    Yes. That's the sequence. User must manually invoke the pop-up after an
    alarm has fired.
    
    As for the user 'scanning the map(s)', if this means 'looking into'
    several domains to find the entity in question, then the only real
    requirement is to have the highest level map displayed. Alarms 'bubble up'
    from thier originating domain. Scanning, as such, is not required.
    In my case, with 5 Domain icons over a backdrop of the U.S., (1) a Domain
    icon changes color; (2) the pop-up is invoked to see exactly what alarm
    happend on which entity; (3) using the 'Find' option & naming that entity,
    (or via the Navigation window) the operator 'zooms' directly to the map
    section containing the entity. 
    
    In any case, I see your point. Jose Luis' outline is great. You may
    want to consider the system resource/overhead impact for larger nets
    and/or burst of errors.
    Regards,
    Jeff.
    

    Re -.1

    as an operator of a network I may well be looking at node counters etc,
    even isolating the cause of a previous alarm.. which is away from the
    entity which is sending in another alarm.

    I want to continue working on the current place in the map, but want to
    know know the nature of the alarm coming in ....

    Why is having a POP UP with a forced or automated ack such a big deal !?

    Amrit

    without taking too much time to get into it. V1.2 will provide a
    significant amount of NEW notification functions to the user. These
    functions range from the notification window which displays textually a
    brief message (color coded) as new events come in. A mechanism to
    request events as well as alarms from the IM PM; mechamisms to target
    events from one entity to another (or change severity); filter the
    events that are returned to the display; pause and resume notification
    on per domain (not per hierarchy, but specific domain) basis. These are
    on ly the tip of the iceberg. More information as we get into field
    test.
    
    jill
    

    While running a network operation for a medium size network I came
    across yet another alarming notification need.

    Lets say you have a domain with banks in NYC. 30-40 banks.
    Any alarm in this domain is a priority 1 problem.

    A bank goes down, it's domain icon and icons above it go red.

    Next bank go down, well domains are already red... you have missed it
    if you have counted on MB2 ( which is not our case).

    But the basic problem is that one cannot know how many red guys are
    there in a domain. In our case, we try to structure domains by problem
    priority rather then just location. This helps operators to assess
    impact of failures and take right actions.

    I see to solutions to the problem :

    1. display a number of components at fault in the middle or at a side
    of the domain icon. This number will increment when next bank goes
    down.

    2. have a window ( one per call priority), and icons for components at
    fault would pop up in this window. Thus operator does not need zooming
    or walking domain trees and just gets to what counts.

    I see it as a real improvement of operator efficiency in the networks with
    extreme service levels ( as our one...).
    
    This probably could be the only screen ( except the pop-up alarm
    window) that operator should care about. Priority screens or priority
    portion of the screen is also necessary as a mean to structure
    operators work. 

    And if one could have an integrated trouble ticket system, that would
    move the red icon to another, "we are working on it " screen once a call
    is placed, operators would be very happy.

    In other words, DECmcc would have a clear marketing edge if it could
    extend more into being a "decision support"/"structuring work" tool for 
    operators rather then just a network management tool.

    			wlodek

	For internal use....

	Copy the  V1.2  kits just announced in note 3.* and take a look
	at the Notification  Services  PM  (Window).    I think it will
	solve some/most of your needs.

	JCE

 	re :.8

	Wlodlek, 

	You might also be interested by PNMP Alarm Handling capabilities, 
	allowing the operator to have different alarming views of his network 
	called 	Operation Contexts with different filtering criterias and to 
	handle (ack/terminate/associate with Trouble ticket) alarms. 

	PNMP has also an Trouble ticket FM integrated with PNMP Alarm Handling, 
	as well as an Event Logging capability. 
	The algorithm to chnage the colors on the map takes into account the 
	fact that the alarm has been associated or not with a Trouble Ticket. 

	You can find more information in the notefile TAEC::PNMP
	
	Happy reading,

	Best regards,

	Marc.

    re: .8 .9
    
    John is talking about using the notification filters window to setup a
    view of notification to meet your needs. Use the "Applications" menu
    to select the notification application. From the notification window
    that is brought up, select the Filters button to bring up the filter
    window. This will allow you to control the data displayed in the
    notificataion window. Please note though that if you delete (this is
    different than filtering or hiding) a notification in the notification
    window then the appropriate action will be taken to remove the visual
    impact (associated color change) from the map as well.
    
    I would be interested in knowing if you have tried out the EFT kit and
    have any input on enhancements/bugs in the notification displays.
    
    thanks
    jill callander