[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

6114.0. "Thousands of MCC_ALARMS_nnnnnnnn.DAT files ?" by KAOFS::CARSWELL () Wed Sep 07 1994 11:20

	We have encountered a problem, that 'appears' to be related to MCC,
and the symptoms are extremely strange. 

	I have already logged a call with the CSC, but in the interests of
not having to restart MCC unless ABSOLUTELY necessary I thought I'd also ask
if anyone here has seen this problem.

	About 4 days ago, we started accumulating MCC_ALARMS_nnnnnnnn.DAT files
in the SYSMGR directory.  These files  are being created at a varying rate of 
between 4000-10000 per day, and the strange thing is that they are date-stamped
as far back as April of this year?   The information contained in the Alarm
files is potentially valid alarm information from back when the real alarm
fired, but I have absolutely no idea, why the files are being created now, AND
WHY are they not getting deleted. 

	Here are just a couple of the files in question, and as you will
notice, the dates are old.  I KNOW that all of these files were created
yesterday (Sep 6,1994) and assume it was around 10:00. (Notice how the
actual creation time is sequential, but the datestamp is NOT!?)    

MCC_ALARMS_DATA_10000214.DAT;1     2   9-JUL-1994 10:00:02.20
MCC_ALARMS_DATA_10002374.DAT;1     2  12-MAY-1994 10:00:23.93
MCC_ALARMS_DATA_10002765.DAT;1     2   8-JUL-1994 10:00:28.43
MCC_ALARMS_DATA_10002768.DAT;1     2  20-JUN-1994 10:00:27.94
MCC_ALARMS_DATA_10002776.DAT;1     2   2-JUN-1994 10:00:28.08
MCC_ALARMS_DATA_10003435.DAT;1     2  29-JUN-1994 10:00:34.88


And  there is valid data inside these files.
-------------------------------------
| $TYPE MCC_ALARMS_DATA_10000214.DAT;1 |
-------------------------------------
RULE: Domain LOCAL_NS:.cpc Rule ADJACENCY_UP
MANAGED_OBJECT: Node4 LOCAL_NS:.dna_node.cvnx Circuit ETHERNET Adjacent 
                Node CVN80
DESCRIPTION: UP
CATEGORY: ADJACENCY
EXPRESSION: (OCCURS(NODE4 * CIRCUIT * ADJACENT NODE * ADJACENCY UP))
TIME: 9-JUL-1994 10:00:02.14
EVIDENCE: The last event detected: Node4 LOCAL_NS:.dna_node.cvnx Circuit 
          ETHERNET Adjacent Node CVN80 Adjacency up   9-JUL-1994 09:59:29.13
EVENT_ARGUMENTS: Event: Adjacency up  Adjacency Up   Adjacent Node Address = 45.10
PARAMETER: ALERT
DOMAIN: Domain LOCAL_NS:.cpc
SEVERITY:     Critical


	We have VMS V5.5-2, MCC V1.3, we use the MCC_DNA4_EVL process, to 
collect phase IV events, the MCC-EVC-SINK to collect non-MCC type stuff, 
the IP-POLLER process, and the rules in the context of a DETMCC detached
process.  This entire setup has been in use for over a year, and NOTHING
was changed in the setup recently.    AND EXCEPT FOR THIS ANOMALLY MCC 
IS WORKING JUST FINE, IN EVERY RESPECT!


	Any help/suggestions that anyone may provide would be appreciated.
This is a Production System(as usual), and we do not wish to reboot, if
we don't have to.  

	Regards,
		Gord C.
T.RTitleUserPersonal
Name
DateLines
6114.1Check for logfiles with version number = ;32768 and delete em.STKMCC::LUNDNiklas LundWed Sep 07 1994 14:450
6114.2Reboot cleared the problem.KAOFS::CARSWELLSun Sep 11 1994 21:3021
	Just in case anyone encounters this one..... 

	We opted to reboot the system, and this strange problem disappeared.
There were no ;32768  files around(.LOG or otherwise) although a good 
suggestion for sure.  Thanks.


	Although a restart of MCC 'may' have cleared the problem, we opted
for the reboot since we have very limited  allowable downtime.  Killing
the fly with a shotgun(the reboot) may be a bit excessive, but the result is
usually pretty predicitable, and as illustrated here, provided the desired
result!

	Regards,
		Gord C.