[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

2889.0. "T1.2.7 EFT2 SNMP_AM and UCX T2.0-18 will CRASH VAX/VMS V5.5" by CUJO::HILL (Dan Hill-Net.Mgt.-Customer Resident) Thu Apr 30 1992 02:11

    This will obviously be bad news if not resolved.
    
    Running DECmcc/VMS T1.2.7 and UCX T2.0-18 on a VMS V5.5 system don't
    get along well.  I understand that some members of your group have
    seen this on occassion, but I can repeat it at will.
    
    Whenever I select an SNMP entity and select more than one partition via
    the List Box, VMS bugchecks with its nose stuck in the UCX BGDRIVER.
    
    Example:
    	-Click on SNMP entity
    	-Click on SHOW COUNTERS & CHARACTERISTICS in the List Box
        -Click OK or APPLY
    	-Two windows come up and VMS bugchecks.
    
    This also happens when a global alarm rule is active [e.g.,
    (OCCURS (SNMP * ipReachability = DOWN))  ]  and I try to issue a
    SHOW IDENTIFIERS via the list box for an SNMP entity.
    
    I tried for 30 minutes to get BRIDGE, STATION, and NODE4 entities to
    crash the system, but couldn't.  I could crash my system (and did 6
    times over two days) by doing two things at once via the IMPM.  Never
    tried via FCL.
    
    We have crash dump info and one member of our group is working with
    Alex Conta (TCP/IP Services for VMS V2.0 - Development Engineer).  
    
    Any comments or suggestions would be greatly appreciated.
    
    Thanks,
    Dan
    (303)-341-3574

T.R	Title	User	Personal Name	Date	Lines
2889.1	QAR 2849 to track	TOOK::MINTZ	Erik Mintz, DECmcc Development, dtn 226-5033	`Thu Apr 30 1992 10:03`	9
	This does look like a UCX problem, since the crash is in BGDRIVER. However, we will need to track it since MCC causes the symptom. QAR 2849 Thanks, -- Erik
2889.2	system hang	NSCRUE::KEANE	U.S. NIS Service Engineering and Delivery	`Wed May 06 1992 17:48`	11
	Any news on this? I've got the same software config. I am not seeing a crash but if I do the steps defined in .0 my workstation hangs and I'm forced to reboot. I've also seen this behaviour when I tried to start up exporting for a group of snmp entities. I was successful in starting exporting for decnet nodes and bridges. Am I running into the same problem or does this look like a resource issue? No problems with anything other than SNMP entities. Thanks, Scott
2889.3	No news yet	TOOK::MINTZ	Erik Mintz, DECmcc Development, dtn 226-5033	`Wed May 06 1992 18:20`	6
	Apparently this can occur with earlier versions of UCX as well. We are working with the UCX developers to resolve this problem, but there is no news yet. -- Erik
2889.4	Any news on SNMP_AM/UCX Crash?	CUJO::HILL	Dan Hill-Net.Mgt.-Customer Resident	`Mon Jun 01 1992 02:37`	7
	What is the status on this crash problem? This item really needs to be fixed before V1.2 goes to SSB. I realize that it is most likely a UCX problem, but is anyone seeing it on systems running DECmcc V1.1 and UCX EFT2.0 ? -Dan
2889.5	Can't reproduce with lastest software.	DANZO::CARR		`Mon Jun 01 1992 16:46`	4
	I have tried extensively to re-produce this problem using the latest base level of DECmcc and cma. I can't reproduce the problem, nor can I explain why...
2889.6	QAR 2849 - Answer	TOOK::MINTZ	Erik Mintz, dtn 226-5033	`Mon Jun 15 1992 10:14`	14
	While we don't know if the bug in UCX has been fixed, we believe we have fixed the DECmcc code that was exposing the crash. Answer for QAR #02849: ------ --- ------- ------- Thank you for your QAR. With older versions of our software, we were also able to cause UCX to crash VMS from DECmcc management windows. We have made numerous fixes, especially to our SNMP AMs select code, and are now unable to reproduce any problems ike this second problem. Our conclusion is that this crash was produced by an invalid usage of the select call which no longer can occur.