[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 10: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.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 6114.1 | Check for logfiles with version number =  ;32768  and delete em. | STKMCC::LUND | Niklas Lund | Wed Sep 07 1994 13:45 | 0 | 
| 6114.2 | Reboot cleared the problem. | KAOFS::CARSWELL |  | Sun Sep 11 1994 20:30 | 21 | 
|  | 
	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.
	
 |