Conference azur::mcc

5937.0. "Double ACCVIO from MCC" by CUJO::BROWN (Dave Brown) Wed Apr 06 1994 15:30

	I've got a customer who is getting very peculiar ACCVIOs. The most 
common ACCVIO is a double one as shown below. Also, there is an occasional
-CMA-F-EXCCOP followed by another type of ACCVIO. 

	These problems seem to have started when I installed the ECO01013
kits on the customer system and has degraded to such a point that MCC won't 
stay up for more that 3 minutes. Oddly enough, this ACCVIO situation only 
occurs when MCC is pointed to the DNS namespace; everything is OK when using 
a local repository. The customer is in most cases doing nothing when the ACCVIO
occurs. They'll bring up MCC, see the Iconic Map come up, walk out of the room 
or talk on the phone and when they get back, the ACCVIO has occurred. This 
happens with the notification startup procedure enabled or disabled.

	I have checked the SYSGEN parameters and the process quotas on the 
system and all are very high and under utilized. MCC_AUDIT runs without a 
problem. 

	Also, just this morning

	These are the kits that were installed under ECO01013:

			- MCCFCLECO01013.A
			- MCCKRNECO01013.A
			- MCCPAECO01013.A

	This is the double ACCVIO:

--------------------------------------------------------------------------------

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00F9DDEC, PC
=000FE595, PSL=03C00000

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=67140719, PC
=80000010, PSL=03C00004

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

	Number = 00000005		 815AE440
	Name   = 0000000C		 00000002
		 00000001		 00FA18C0
		 67140719		 00FA18A8
		 80000010		 00000004
		 03C00004		 0000C082
					 00000001
					 03C00000
					 7FEF8B68
					 03000001

	Register dump

	R0 = 03C00000  R1 = 67140719  R2 = 00083858  R3 = 00FA1AD8
	R4 = 00FA1AD8  R5 = 00FA1AD8  R6 = 000AF9DC  R7 = 00001400
	R8 = 00000006  R9 = 00D87224  R0=  00DBAC8C  R11= 00DB8B69
	AP = 00FA185C  FP = 00FA181C  SP = 00FA1898  PC = 80000010
	PSL= 03C00004

-------------------------------------------------------------------------------

	Please, if anyone has any ideas, please let me know. This is a large 
customer as we will have to quickly escalate if we can find no solution. 

	Today, I will be installing the latest DECWindows and Motif patches
per the Support Center's recommendations. When bringing up MCC, there are a 
few X errors which occur. The patches we will install are CSCPAT_1053016 and
CSCPAT_0372010.

	Dave

There is a problem with the Kernel ECO that can be fixed easily by
defining a logical. I've included the README file (you probably missed 
this info, depending on when you copied the ECO kit).

*Robert


	This file contains two addendums related to the new kernel
	share for VMS 6.0
	=============================================================



	The two items:

	  1)	After release of this eco, we found scenarios where
		the iconic map crashed. The fix was simple; bump the
		value of the following DECmcc logical up to 40.

		define MCC_NOTIF_GETEVENT_TSS 40

	   	(The scenario which helped bring out this error was when
		 the notification window came up before (automatically
		 on load) the map.)

		Symptoms:

			Access violation occurred while clicking in
			iconic map. i.e. Opening or creating a new domain.

	  2)	One of the steps in README_KERNEL_UPDATES_1.TXT recommends
		the following:

		-- 2) Copy both MCC_KERNEL_SHR.EXE and MCC_MTS_PRIV_SHR.EXE
		      into:
			        SYS$COMMON:[SYSLIB]
  
		I would recommend copying the two files above into

				sys$share

		I've found scenarios where what is in SYS$COMMON:[SYSLIB]
		is not the first element in the sys$share search list and
		thus is not grabbed. Put another way, when you grab
		sys$share:MCC_KERNEL_SHR.EXE or sys$share:MCC_MTS_PRIV_SHR.EXE
		make sure you grab the eco ones.

							JS

    
    
    	Looks like the first suggestion in .1 might have done the trick;
    the customer's MCC session has now been up for 4 hours...Thanks!
    
    	The kernel images were properly placed in SYS$COMMON:[SYSLIB].
    
    	What is strange is that this ACCVIO happened in exactly the same
    way with the V1.3K-01 and V1.3K-02 Kernel images. The V1.3K-02 images
    were put on yesterday in an attempt to solve the problem documented in
    the base note. Unfortunately, I didn't see the part about defining
    MCC_NOTIF_GETEVENT_TSS. For the sake of information, the customer's
    environment is one of VMS V5.5-2 and not V6.0
    
    	Dave

    
    	Just for everyone's information, I have been getting ACCVIOs of the 
    type documented in the base note with MCC_NOTIF_GETEVENT_TSS set to 40. 
    This was happening on just one machine within 3 minutes of bringing up 
    the iconic map. They stopped when I increased the value to 50.
    
    	Dave