[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 20: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 05: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 08: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 09: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 09: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
    
 |