[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 |
5950.0. "MCC Access violation" by CSC32::B_GOODWIN (MCI Mission Critical Support Team) Mon Apr 18 1994 21:14
My customer, MCI, is having the following problem with access
violations in MCC. Can anyone shed any light on the problem or give me
some directions as to what to look at.
Thanks,
Brad
From: DECPA::"[email protected]" "Scott Keane" 18-APR-1994 17:57:37.77
To: Brad Goodwin <csc32::b_goodwin>
CC: Scott Keane <[email protected]>
Subj: mcc access violation
Brad,
Here is the access violation that I am seeing on the new mcc cluster. I have
checked the DSNlink polycenter database and don't see any articles that
related. I will log a call on it in the morning but wanted to give you the
information asap. This happens every 10 minutes or so.
System is 4500A running VMS V5.5-2, DECnet-OSI, and Polycenter NM V1.3. I
thought this may have started when I was using the customized icons. I have
since changed back to all standard icons but the problem continues. I plan to
reboot the machine to see if that makes any difference. I don't have to do
anything except start the iconic map user interface to see the problem.
$ mana/ent/int=decw
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=26E69F1C, PC
=011496D7, PSL=03C00000
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
0004B4C4 0004B4C4
0007C382 0007C382
000771DC 000771DC
0007A878 0007A878
Thanks,
Scott
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: by mts-gw.pa.dec.com (5.65/13Jan94) id AA11218; Mon, 18 Apr 94 16:50:06 -070
% Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA15441; Mon, 18 Apr 94 18:50:43 -050
% Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ef03286; 18 Apr 94 23:27 GM
% Date: Mon, 18 Apr 94 18:32 EST
% From: Scott Keane <[email protected]>
% To: Brad Goodwin <csc32::b_goodwin>
% Cc: Scott Keane <[email protected]>
% Subject: mcc access violation
% Message-Id: <55940418233255/[email protected]>
T.R | Title | User | Personal Name | Date | Lines |
---|
5950.1 | | BIKINI::KRAUSE | European NewProductEngineer for MCC | Tue Apr 19 1994 06:15 | 6 |
| This is the kind of failure that can be caused by virtually anything.
I would start with a run of MCC_AUDIT to check quotas and sysgen
parameters. Do you run alarm rules and/or get events?
*Robert
|
5950.2 | MCC_AUDIT was run | CSC32::B_GOODWIN | MCI Mission Critical Support Team | Tue Apr 19 1994 09:42 | 6 |
| Yes, MCC_AUDIT has been run and everything is ok. They do have many
alarms set up. They are using MCC to monitor about 30 DECnis' and many
bridges.
Brad
|
5950.3 | A little more info... | CSC32::W_ALEXANDER | | Tue Apr 19 1994 10:51 | 5 |
| The customer also rebooted this system last night and with no alarms
running, he still received the accvio this morning on an idle system.
Will and Brad
|
5950.4 | no alarms... | CSC32::B_GOODWIN | MCI Mission Critical Support Team | Tue Apr 19 1994 10:51 | 5 |
| I just checked with my customer, he does have many alarms rules, but
none of them are active currently and the accvio is still occuring.
Brad
|