[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

2096.0. "Notif. detail window - several duplicated fields" by TAVIS::PERETZ () Tue Jan 14 1992 07:37

The DECmcc Notification: Notification detail" window has some duplicated
fields:

1. Severity.
2. entity.
3. Significance field in the Problem data construct.
4. Information  field in the Problem data construct (just the name).
5. Four different time specifications.

I believe that if we eliminate this duplications we can have a better and 
easier to use window.

T.R Title User Personal
Name Date Lines

2096.1 the joys of being generic and standards compliant... MCC1::DITMARS Pete Tue Jan 21 1992 15:31 22

T.R	Title	User	Personal Name	Date	Lines
2096.1	the joys of being generic and standards compliant...	MCC1::DITMARS	Pete	`Tue Jan 21 1992 15:31`	22
	Thanks for the feedback. Keep it coming. As far as eliminating duplicate information, we will work on this wherever possible. We can probably do something about supressing one or more of the "header" fields that show up in the details box. I think we already do this in FCL. In most cases, we (notification services) have no knowledge about the contents of the event report and therefore can't safely supress anything. It's usually the event-generating-MM-developer who has to tweak the event report itself to tone down the redundant or useless information. We've already had a couple passes at the Alarms event report. I say "usually" because in cases where the arguments of the event report must be standards compliant we could reason about the contents and supress duplicate information. Unfortunately, it seems that the standards also dictate that the event reports contain the information that we end up wanting to supress. :^)

Thanks for the feedback.  Keep it coming.

As far as eliminating duplicate information, we will
work on this wherever possible.  We can probably do 
something about supressing one or more of the "header"
fields that show up in the details box.  I think we
already do this in FCL.

In most cases, we (notification services) have no 
knowledge about the contents of the event report and 
therefore can't safely supress anything.  It's usually
the event-generating-MM-developer who has to tweak the
event report itself to tone down the redundant or 
useless information.  We've already had a couple passes
at the Alarms event report.

I say "usually" because in cases where the 
arguments of the event report must be standards 
compliant we could reason about the contents and supress 
duplicate information.  Unfortunately, it seems that
the standards also dictate that the event reports contain
the information that we end up wanting to supress.  :^)