Conference azur::mcc

    currently the mechanism to reset occurrences can not be disabled,
    we actually hadn't even thought about it. As to the clear event, alarms
    in V1.2 does support that. It is capable of monitoring an attribute for
    a threshold or change and tell you when it has changed and then clear
    it when it has reverted into its' non alarmed state.
    
    This probably doesn't meet all ofyour needs, but we can talk when
    you are in the US if it can wait that long.
    
    

re. 2171.0

>The question is if this behaviour can be achived with DECmcc?
>With the notification services the notification of an event is
>shown in the notifification window, and does not disapear when
>the user does a 'reset selected alarms' in the map.  but if the
>user selects a notification in the notif-window, it can be
>deleted.  The PTT would like the possibility to disable the
>ability of manual deleteion of a notification and only allow a
>deletion by sending a 'clear'-event.  Is this possible in any
>way?


I don't think this is a good idea.  I can forsee people using logging of events
in the Notification Window as a sort of "heads-up audit trail".   

What about this:  Instead of deleting the recored for the event window, why not
generate a "local event" in the Notification Services event window indicating
something like 
	"Event XX for NODE .foo was cleared by manual intervention by 
	 FOOBAR::OPERATOR at 23-JAN-1992 19:40" 

That way the operator can search through the event window (using the filtering
capability) to see which events (if any) had been manually reset by an
operator. 

Is that a reasonable alternative ? 

/doug

repl .2

>>> What about this:  Instead of deleting the recored for the event window,
>>> why not generate a "local event" in the Notification Services event
>>> window indicating something like 	
>>>          "Event XX for NODE .foo was cleare by manual intervention by 
>>>  	     FOOBAR::OPERATOR at 23-JAN-1992 19:40" 

>>> That way the operator can search through the event window (using the
>>> filtering capability) to see which events (if any) had been manually reset
>>> by an operator. 
    

Hmmm....., okey, that's a walk-around.  The answer (from the PTT) is that 
when they change operator shift, the new operator does not see a picture
that reflects the current state (which they do today at the PTT).
They didn't like the idea of having the leaving operator 'report the
current state' to the operator starting the shift or having the new
operator to investigate the history to get knowledge of the current state. 

I, think that this question is a matter of education: simply tell the
operators *NOT* to delete the notifications (of a certain kind eventually)
manually.  Unfortunatly the PTT does not agree on that.

One idea that struck my mind was to have a read-only-window  displaying the
notifications and/or events which is totally controlled by software.  The
problem is which MM is responsible for it? The PTT-developed AM only sees
the events comming in, and not the notifications.  It would be great if
there were any possibilities to register a callback-routine which would be
called when notification occurs. However, that's just an idea, I don't know
how to solve that...

They are sending 2 guys to an AM-development class in the beginning of
february, so I see that as a signal that they are very close to a
commitment for DECmcc, but this is still a seriuos key issue.


Any more ideas are very welcome.

   Thanks
       /Nils

    	I take it the PTT doesn't trust the operators enough to
    give them the authority to delete (i.e. clear) notifications?
    If so, then perhaps a rule with a repeating (polling) interval
    could be to resend notifications on the same event periodically
    until the event is cleared.
    
    	Another workaround involves the way in which the operator
    "acknowledges" the notification.  Let's say that instead of
    deleting notifications, that instead, operators are trained to
    use the Notification Filters window to filter out notifications
    as they acknowledge them.  This way, the notifications remain
    in the Notification queue (limited by the maximum size of the
    notification queue), but the operator is no longer forced to
    wade through them on the screen.  The effect is similar to that
    of a notification "delete" from a user's perspective, but the
    notification actually still exists and is only being filtered
    from the notification display.  When the next shift operator
    shows up, the older notifications can be displayed by simply
    disabling and/or modifying the current notification filtering.

    				-davo

p.s.	Stay tuned for the Notification Logging feature (to be included
    	in the actual SSB release of V1.2) which logs all notifications.
    	The presence of a log will allow recording of all notifications
    	and might discourage unauthorized notification deletions by
    	operators (if in fact the PTT wishes to discourage operators
    	from deleting notifications as you described).

Being able to disable the "reset selected/all alarms" and "delete notifications"
buttons in the Map window and Notification windows wouldn't be that hard.  With
some minor edits to our DECwindows UIL, we should be able to provide a way of 
doing it via the X resource manager.  Once you have the names of the relevant 
widgets, you could add a resource to your operator's decw$xdefaults.dat file 
that would desensitize the buttons that the operator would normally use to 
delete notifications.

Getting this (or a more formal) mechanism into the product this late in the 
cycle would require you elevating it high and fast, since it involves risk and 
some shifting of already too tight schedules.

Talk to product and engineering management.  Include fun figures like how many 
sales this would gain us.

The flashing-till-acked behavior sounds good too, but that would require more 
work.  Depending on how they plan to implement all this, you could make a 
similar scheme work with V1.2 not with flashing, but with multiple severity 
levels, and either a normal directive or an enrollable widget from the IMPM.
For example:

		Critical	-	Un-acked person in building
		Major		-	Acked person in building
		Clear		-	Nobody in building

When person arrives, detection mechanism posts event with severity critical.
Operator acks by selecting entity and using Operations->Acknowledge function
(built by your customer) which results in event being posted with severity
Major.  Since it's the same event, the icon should change from Critical to
Major color.  When detection mechanism sees person leave, it posts same
event with Clear severity, and icon should change from Major to Clear.

Unfortunately, I don't think the above can't be done with V1.2 alarms, since 
it would require the "correlated notifications" mechanism to be implemented
(which isn't), or something else that would associate different severities
with different ranges of attributes.  But it could be done by the customer.

All of this should definitely hit the next version's phase 0 list.

I will attempt to name the widgets that you need to desensitize and test the
theory in my spare time.  :^)

My manager said it was worthwhile.