[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 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.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 14:45 | 0 |
6114.2 | Reboot cleared the problem. | KAOFS::CARSWELL | | Sun Sep 11 1994 21: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.
|