[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

836.0. "Does MCC collapse redundant errorlog type events" by GRANE::HEINTZE () Fri Mar 22 1991 19:54

I hear that DECmcc provides a means to collect information on (say, storage)
devices.  I'm looking for the kind of information that you would see in
a VMS error log.

I perused the table of contents of my MCC system reference manual but could find
no hints on where this might be documented.  Can someone point me to the place?

I need to find out how MCC implements this because I am worried about redundant
event correlation.   Currently in VMS, this is a problem because (as you 
probably know) an HSC broadcasts its information to every cluster node but
does not guarantee delivery of any of these packets of information.  Consequently
it is necessary to read all the VMS error logs and sort out the duplicate 
events.  This is how VAXsimPLUS works.

Is it necessary to perform this kind of gymnastics when utilizing the capabilities
of DECmcc?

                              Sieg

T.R	Title	User	Personal Name	Date	Lines
836.1	Duplicate detection	CAPN::SYLOR	Architect = Buzzword Generator	`Mon Mar 25 1991 00:13`	8
	I don't think MCC does that. However, when VMS switches over to using EMA events, it will become possible. In EMA, each event report has a UID, send the event to 30 places, then merge the files, and the UIDs will let you detect duplicates. PS, anyone want to build an "event correlation FM"? Mark
836.2	event synchronisation	BEAGLE::WLODEK	Network pathologist.	`Mon Mar 25 1991 18:32`	20
	Marc, How will it work with reachability events ? Even if there is a single "event", node going down, this will be detected by several other routers. In theory every event is still different, it simply says that this particular router timed out a node, but may be problematic for changing state of the icon. If a node goes up and down , depending on the timing, and possibly other circumstances, last event can be "down". At least at procedural error, one should always verify that "red" entity is really down via poll. I wouldn't recommend to automate this poll entirely. One should also have infrequent status polls ( hours ?) to check for this very unlikely event. wlodek
836.3	Ah, collapsing different events that say the same thing	CAPN::SYLOR	Architect = Buzzword Generator	`Tue Apr 16 1991 15:13`	14
	Wlodek, Ah, that's not quite the case I was talking about. You want to have something that watches over a "node" and if any router realizes the node is unreachable, then it fires of a statement that the node is down (NOT the router) and then ignores any other reachability events from other routers about that same node. That's a more difficult problem than the one I was talking about. However, it is important. I've been looking at some AI and some simulation based approaches to this more difficult problem, but answers are hard to come by. Contact me off-line if you're interested in more info Mark