Conference azur::mcc

The management window messages: unexpected information was returned ...

	says that attributes with codes 4,5,6,7,8 were returned in outp.
	However the form which was created according to the information
	requested and dictionary definitions regarding variants and the
	predictability of attributes was such that those attributes were
	not expected to be returned.

Verna

    Thanks Verna,
    
    any ideas about the second part of my question ?
    

--ATTRIBUTE NOT GETTABLE is returned in outp as the value for a particular 
attribute.  

Anyone up in SNMP land want to comment on version mismatch with Wellfleet?

Verna

    Attribute not gettable is returned when the wellfleet agent returns a
    nosuchname error when a particular object is requested.  This is very
    likely a problem with a version mismatch between mib definition and 
    wellfleet agent.
    
    The problem with chipcom and synoptics is more curious.  It seems as
    though the AM is returning attributes that the map isn't expecting.
    This shouldn't happen.  Can you provide more specific info about what
    you were looking at when this problem occurred?
    
    Thanks,
    
    	Rahul

    Yes I can provide more specific details about the operations,
    but not until Wednesday. As soon as I'm back in the office
    I'll let you know exactly how we are provoking the error
    messages with the Cabletron devices.
    cheers,
    Denis
    
    
    
    
    

    Hi again,
    
    I had a LONG Christmas break.
    Anyway , it is quite simple to provoke the 
    ATTRIBUTE NOT GETTABLE(ugly message that!) message
    by requesting information for ANYTHING located under :
    
    snmp <INSTANCE> cabletron device
                                          
    We have managed to rule out the cabletron agent software
    as the source of the error by requesting the same information
    from the Hp network management station - which is also being
    tested by the customer and is located right next to the DECmcc
    machine....
    cheers
    Denis

	Denis,
		The reason you see this problem is the way Cabletron has
	defined their private mib. They do not use the SEQUENCE OF construct
	to define columnar objects, which is the standard way of defining
	tables. They just stick in an INDEX clause in a normal object definition
	and have a textual description which explains that it is a table
	element.

		Since it would be difficult for Cabletron to modify their
	mib at this late juncture, and since they are one of the strategic
	vendors, we have modified the mib translator to handle this special
	case. One of our customers at Martin Marietta has already used 
	it with some success.

		This fix will be available in our next release. Or if you
	are too eager to try it out you can copy it from 
		YAHEY::YAHEY_USER:[BOSE.PUBLIC]MCC_TCPIP_MTU.EXE

	Rahul.

    Rahul,
    
    That is extremely good news! I'll explain this to the
    customer as soon as possible, however rather than waiting 
    for the new release I'll copy across the fixed translator.
    As soon as we've tested it on site I'll let you know how
    it went.
    It'll probably be late next week before I know...
    
    cheers
    Denis
    

    Hi yet again,
    
    to anyone still interested in knowing if the 
    debugged mib translator works in V1.1......
    it does indeed!!.
    The cabletron equipment is now manageable.
    Thanks to all those who helped especially Rahul.
    
    cheers
    Denis

Re: .7-.9

I'm running DECmcc T1.2.4 on VMS V5.5, and had the same problem with
Cabletron devices using the distributed MIBDEF.  When I spotted this
note, I copied the fixed MIB Translation Utility image and the
MIBDEF.TXT file (same as the on the kit), but discovered that it won't
compile on my system(see following).  Note that the distibuted MTU
image successfully compiles the same MIBDEF.

	- Andy

The last few lines of the listing file contain:

4619
Index Node redundCircuitNumber not found
exiting program....

******************Log of MTU translation
***************************************

vnet68#@mcc_tcpip_mtu

Welcome to the DECmcc TCPIP MIB Translator Utility driver procedure T1.2.4

  13-MAR-1992 16:35:40

This procedure operates in a 2 phased manner --
Phase 1 translates the MIB definition into a management specification.
Phase 2 (as an option) translates the management specification into a
  dictionary loadable file and loads the dictionary.

Phase 1 -- Enter name(s) of file(s) to translate
  (separate multiple files by commas): del SYS$COMMON:[SYSEXE]MCC_TCPIP_MTU
.EXE;
  (separate multiple files by commas): cabletron_mibdef.txt
Phase 2 -- Do you want to update the DECmcc data dictionary? (Y/N) [N]:

Issuing following command:
  $ MTU = "$ SYS$SYSTEM:MCC_TCPIP_MTU.EXE"

                                   * * *

Beginning Phase 1 for file DKB0:[MCC]CABLETRON_MIBDEF.TXT;
Now starting to run the MIB translator...
This may take approximately 1-5 minutes.
  13-MAR-1992 16:35:52
Issuing following command:
  $ MTU DKB0:[MCC]CABLETRON_MIBDEF.TXT;
Index Node redundCircuitNumber not found
exiting program....
An error occurred while running the MIB translator.
Check file DKB0:[MCC]CABLETRON_MIBDEF.LIS for any further information.
File DKB0:[MCC]CABLETRON_MIBDEF.MS may also have been created;
  delete this file as appropriate.

  13-MAR-1992 16:36:08

Procedure terminated in error.
vnet68#
 

	Andy,
		There is a bug in the Cabletron mib. It references the object
	redundCircuitNumber in an INDEX clause, but no such object has been 
	defined or imported into the mib.

		This has been fixed and the newest BMS kit has the fixed mib.
	If you are unwilling to wait till you get the latest base level kit,
	you can copy the mib from 

		YAHEY::YAHEY_USER:[BOSE.PUBLIC]CABLETRON_MIBDEF.TXT

	Rahul.