[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

1044.0. "EVT_POOL_CORRUPTED error" by MFRNW1::SCHUSTER (Karl Schuster @MFR Network Services) Thu May 23 1991 07:37

    I use BMS V1.1 + TCP/IP AM V1.0
    
    I have set up about 50 alarm rules ( node4, bridge, snmp components ).
    The polling interval for the rules is 5 minutes.
    
    The alarm process runs in batch ( from 6 AM to 11 PM, and restarts
    itself for the next day 6AM).
    
    2 DECwindows userinterfaces are normally active, with notification enabled.
    
    Everything worked fine for about 1 week. 
    
    Yesterday I started the DECwindows userinterface and I got the
    following error:  MCC-F-EVT_POOL_CORRUPTED
    Notification could not be used. In the .LOG file of the batchjob, where
    the alarm rules are enabled, there are ACCVIOs with the ENABLE alarm
    command.
     
    I deleted all the rules, and created them again. The problem
    disappeared.
    
    Is this a known problem, or do I have insufficient quotas or parameter
    settings ?
    
    Regards, Karl

T.R	Title	User	Personal Name	Date	Lines
1044.1	I guess there is first time of everything	TOOK::GUERTIN	I do this for a living -- really	`Thu May 23 1991 13:16`	20
	This has never happened before. Whenever a process uses the Event Manager portion of MCC, an initialization routine is called which maps in the VMS global section and does a consistency check. In your case, the consistency check failed. Seeing how this is the first time I've heard of this message getting displayed, I would chaulk it up to being a fluke. If you see it again, then I would consider this a serious bug. You didn't have to go to the lengths of deleting the alarms rules, etc. Whenever all the processes using the Event Manager stop using it, the Event Pool gets re-initialized on the next access. In fact, if this didn't work, then it would imply a VMS restriction (read "bug") that we are not aware of. Some questions: Have you applied the Alarms-FM patch which was posted in this notesfile? Have you been killing processes running MCC (e.g., $ STOP/ID=xxxx)? Have you seen anything else weird going on in your system? -Matt.
1044.2		MFRNW1::SCHUSTER	Karl Schuster @MFR Network Services	`Thu May 23 1991 13:32`	5
	I have copied the patch, but not yet applied. Yes, there have been several windows open, with notification enabled. I will apply the patch and see whether it happens again.
1044.3	stop the apps too	TOOK::CALLANDER		`Thu May 23 1991 14:09`	1
	make sure that all mcc sessions are also exited before testing it.
1044.4	another corrupted event pool	MFRNW1::DENIS		`Mon Dec 16 1991 09:32`	12
	Hi , I have also, and just very recently experienced the "MCC_EVENT POOL CORRUPTED" error message. The version is V1.1.0 with all available patches applied. The installation was OK in this respect for more than a month, and then this error message appeared suddelly and out of nowhere. cheers Denis
1044.5	Can anyone help with cause of this error?	MICROW::LANG		`Fri Mar 06 1992 11:46`	13
	Hi. Recently I got the EVT_POOL_CORRUPTED error, but I'm not using events or alarms, on ultrix EFT 1.2.4. Sometimes I use kill -9. Could anyone help with a reason? It happens out of nowhere, and goes away out of nowhere!!! thanks in advance. Bonnie > Have you been killing processes running MCC (e.g., $ STOP/ID=xxxx)?
1044.6	Try clean-up with ipcrm	TOOK::MINTZ	Erik Mintz, DECmcc Development, dtn 226-5033	`Fri Mar 06 1992 12:40`	9
	The event manager is used by the kernel, regardless of whether you use it explicitely. It is possible that your kill -9 is corrupting the shared memory used for the event pool. To correct the problem when it happens, try using "icps" to show the allocated shared memory, and "ipcrm -m #" to remove the shared memory segment numbered #. (Shut down all of your DECmcc processed before removing the shared memory)