[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

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.RTitleUserPersonal
Name
DateLines
5950.1BIKINI::KRAUSEEuropean NewProductEngineer for MCCTue Apr 19 1994 06:156
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.2MCC_AUDIT was runCSC32::B_GOODWINMCI Mission Critical Support TeamTue Apr 19 1994 09:426
    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.3A little more info...CSC32::W_ALEXANDERTue Apr 19 1994 10:515
    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.4no alarms...CSC32::B_GOODWINMCI Mission Critical Support TeamTue Apr 19 1994 10:515
    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