[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

4187.0. "CONC Rule exception, INV_HANDLE error" by ZUR01::FUEGLISTER (Roland Fueglister, 760-2498) Thu Dec 03 1992 07:36

The following alarm message is an extract from the 
mcc_common:mcc_alarms_dd-mmm-yyyy_error.log files. The alarm rule will be
disabled/enabled each day at midnight. The error happens always after ~5 hours.

The same error can be reproduced by issuing the following command:

mcc>show conc .grd.bern.es.fc_ks19_u108_1 PHY Port *A Phy Port State, -
								at every=00:03

The VMS DECmcc/BMS version as well the Conc AM version is V1.2.0


 >>> 30-NOV-1992 05:00:07.48   Domain EMD:.DOMAIN.BERN_KS19_21 
					Rule fddi_conc_monoring_down 
     Expression = (CONCENTRATOR .grd.bern.es.fc_ks19_u108_1 PHY Port *A 
				 Phy Port State <> in Use, at every=00:03)
     Status     = %MCC-E-INV_HANDLE, software error: invalid handle parameter

MCC 0 ALARMS RULE fddi_conc_monoring_down 
AT 30-NOV-1992 05:00:07 


In the meantime, I have created two rules instead of using the wildcard
feature.


			Best Regards,

			Roland
T.RTitleUserPersonal
Name		DateLines
4187.1Bridge AM has the same problemQUIVER::HAROKOPUSThu Dec 03 1992 09:147
    Roland,
    
    We are experiencing the same problem with wildcarding on the bridge AM.
    We haven't been able to isolate the problem yet.   I'll add your
    information to the Bridge wildcard QAR.
    
    Bob
4187.2possibly related problem?MCDOUG::MCPHERSONpre-retinal integrationThu Dec 03 1992 09:2610
>    We are experiencing the same problem with wildcarding on the bridge AM.
>    We haven't been able to isolate the problem yet.   I'll add your
>    information to the Bridge wildcard QAR.


Does the same problem exist whether or not use Local MIR or DNS? If it goes
away when you use DNS,  I think I may know where the bug is. (We located what
looks like a 'handle handling' bug in the Translan beta code...)

/doug
4187.3QUIVER::HAROKOPUSThu Dec 03 1992 13:099
    Interesting.  We can reproduce it on the bridge with a local MIR but 
    we haven't tried it with DNS.   Will anyone who has experienced this
    problem on DNS pleae let me know?
    
    Doug, what was the bug that you found?
    
    Thanks,
    
    Bob
4187.4TOOK::MCPHERSONpre-retinal integrationThu Dec 03 1992 14:0018
The translan code (and likelt the *old* bridge AM code) was using the *value*
of 'handle' in "mcc_ahs_handle_create(handle)" instead of passing 'handle' by
refererence...  

The DNS codepath ignored the bogus handle info in the subsequent
mcc_dns_get_ident() call, cuz it didn't use it, but the local MIR code *uses*
the handle, and subsequenty caused MCC to ACCVIO rather quickly.

I looked over the 'C' version of the bridge AM code today and this problem
*was* fixed, so it's probably exactly your problem.  

Since I think the only routines that will give you the 'invalid handle state'
message are the mcc_ahs* routines, the obvious thing to do is grep through the
AM code for any of the mcc_ahs* routines and make sure that the handles created
for those calls were created anbd reference correctly.   But then you've
probably already done that by now...

/doug
4187.5DECdns V1.1 is the MIRZUR01::FUEGLISTERRoland Fueglister, 760-2498Fri Dec 04 1992 02:5911
RE.: .3

I experienced the error described in .0 using DECdns V1.1 as the MIR. DECdns
and DECmcc are installed on the same system.


				Best Regards,


				Roland