[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

3988.0. "Notify counter to restart every day." by MEO78A::BARNHOORN (Barney to his friends) Wed Oct 28 1992 23:03


Hi,

I have a question regarding the notification window/log.

You can have the notification log, create a new version every 24 hours 
(usually at midnight).

How can I get the notification number also start again?  (automatically)

If you receive lots ( because of PCSA , the customer what to know when all nodes
go up and down), the max number of notifications is reached fairly quickly, even 
if you set a high number.

Also having the counter restart at midnight the customer has an idea on the
number of events per day.

thanks

Mark.
T.RTitleUserPersonal
Name
DateLines
3988.1MCC1::DITMARSPeteThu Oct 29 1992 19:4733
>How can I get the notification number also start again?  (automatically)

There's no way to do this.

>If you receive lots ( because of PCSA , the customer what to know when all nodes
>go up and down), the max number of notifications is reached fairly quickly, even 
>if you set a high number.

Are you confusing the "ID" number that identifies
each notification and the customizable number that determines the size of
the notification buffer?  The two are numbers are independent.  

A notification ID is just a tag to help users "name" a notification.
The buffer size controls how many notifications can be kept in memory.

>Also having the counter restart at midnight the customer has an idea on the
>number of events per day.

There are a whole lot of things that we should be able to do with
notification data that we presently can't do.  Among them:
	- record them permanently in a more usable format than
	  plain ascii
	- retreive/playback recorded notifications via the same or similar
	  presentation mechanisms
	- use various powerful visualization tools to help perform
	  various management tasks based on notification data
	- share the data intelligently among various interested
	  managers 

TeMIP did some of these things already by putting another layer on top
of the events/notifications to create "alarm objects".  The next generation
of notification services should probably move in a similar direction
rather than one-plussing the current design.