Conference azur::mcc

    Had a quick look...

    Looks like the mib does not start with the usual IMPORT statement or
    begin etc...

    have a look at the mibs supplied on a mcc system.  You should see that
    at the begin a IMPORT imports the full roots etc...

    Amrit

    
    
    Thanks Amrit, indeed the information for the imports, once included let
    the MIB compile, for a while.  
    
    Now for the next problem... a syntax error on line 2042, Trap-PDU.  I
    notice in the supplied MIB definition, this line and all lines after it
    have -- in front of them.  Is this equivalent to a comment statement?
    Also the END statements are in different places.  The Chipcom supplied
    MIB has the END before the Trap-PDU line...maybe trying to finish the
    "compile" at that point, but it keeps going anyhow??!!  I assume I must
    add the -- characters into this portion of the new MIB and move the END
    statement, but would like to be sure and also to understand a little
    about what to look for in future MIB supplied by vendors. 

    
    Thanks,
    
    Dave
    

	Dave,
		I took a look at the chipcom mib. Besides the missing
	header information, the trap definition is pretty messed up and
	have to be commented up. I also noticed that half the tables are
	defined incorrectly.

		The cleaned-up mib which compiles correctly is located at
	YAHEY::YAHEY_USER:[BOSE.PUBLIC]CHIMIB2.ASN
	Do a diff with the original file to find out what changes had to be 
	made.

	Hope this helps.

	Rahul.

>        Besides the missing
>        header information, the trap definition is pretty messed up and
>        have to be commented up. I also noticed that half the tables are
>        defined incorrectly.

    Will vendors ever learn how to write their MIBs in a standard form?
    Should we provide a training on this? Should we provide a "Convert
    MIB to standard" service? Should we improve our MIB translator to
    'guess' missing headers and discard 'messed up' portions and fix
    incorrect table definitions?
    
    I'm really getting tired of convincing customers that it is NOT
    MCC's fault. They say "I got this MIB from vendor XYZ and it doesn't
    compile with MCC. The vendor says, his MIB is ok - so it must be a
    bug in MCC".

    *Robert

    
    
    Hi everybody,
    
    That private CHIPCOM MIB seems to correspond to the EMM V2.1 CHIPCOM
    Management Module Agent.
    
    Simply for your information, you can obtain from CHIPCOM Europe 
    (via specific contract) a new kit of the EMM called EMM V3.0 Basic. That 
    new agent corresponds to a new private mib called 
    CHIPCOM_HUB3_BRG_10BT_MIBDEF.TXT ASN.1 file (already set in the T1.2.7 kit).
    
    That great advandtage of that new mib is to be more ergonomic and
    more user-friendly (just details regarding to the added ability to manage
    Token-Ring modules, and to introduce also co-existence of ETHERNET/TOKENring
    and FDDI... + new modules...).
    
    Renato
    
    PS : The EMM hardware module can be downloaded with a PC + PROCOMM
    (software) via the RS232 serial local console port.
    
    PPS : With the T1.2.7/T1.2.8 MIB Translator Utility, you can also have
    to "branch" in the private CHIPCOM tree (CHIPCOM CHIPMIB01 and CHIPCOM 
    CHIPMIB02) corresponding respectilvely to CHIPCOM_HUB3_BRG_10BT_MIBDEF.TXT
    and CHIPCOM_HUB21_MIBDEF.TXT ASN.1 files (note that the first file must be
    compiled FIRSTLY before the second file... maybe a MTU bug...)... So
    you can manage (and compare) different EMM SNMP agents...
                                                                               

    
    Just in from the UK.  Chipcom admitted this morning that the MIB they
    sent SmithKline was bad and would not compile. They also indicated that
    the one in the MCC kit is ok.
    
    Thanks for all the assistance.
    
    Dave

	RE .5

>>    PPS : With the T1.2.7/T1.2.8 MIB Translator Utility, you can also have
>>    to "branch" in the private CHIPCOM tree (CHIPCOM CHIPMIB01 and CHIPCOM 
>>    CHIPMIB02) corresponding respectilvely to CHIPCOM_HUB3_BRG_10BT_MIBDEF.TXT
>>    and CHIPCOM_HUB21_MIBDEF.TXT ASN.1 files (note that the first file must be
>>    compiled FIRSTLY before the second file... maybe a MTU bug...)... So
>>    you can manage (and compare) different EMM SNMP agents...
 
	There has always been some confusion regarding the MIB translation
	utility, and the command/shell script which runs this translator 
	and loads the mib into the DECmcc dictionary. This confusion is
	understandable since they both share the same name.

	What you are talking about is the MTU command script. This script
	has to jump through hoops, and edit DAP command files to do what
	you described above, since currently, DAP does not provide a clean
	way to merge two entity models together. Consequently, there are
	some restrictions regarding the order in which mibs are added to
	the dictionary. We are hoping that in the next version of DECmcc
	DAP will provide the functionality to do this properly, which will
	allow us to remove a lot of the current restrictions.

	Rahul.

    Please help me understand.
    
    Am I to assume that Chipcom is NOT writing an AM for DECmcc, that would
    allow a graphical view of the hub, turning ports on and off...etc., any
    management will be via the SNMP AM and Chipcom's MIB??
    
    Please explain.
    
    Regards,
    
    Ken
    

    
    
    Hi Ken,
    
    The only information I have are :
    
    	1) There is an agreement between CHIPCOM and DIGITAL to integrate
    CHIPCOM management as their own software do (NCS, which runs already on PC
    and SUN-UNIX platforms...), on a DECmcc/MSU (ie Management Station for
    ULTRIX, not really an EMA/DECmcc product...). I've talked to CHIPCOM
    Europe (France) at the beginning of the week, and they've confirmed
    that there is a DECmcc/MSU platform in UK that has a specific CHIPCOM
    software integrated (In BETA test).
                                                                          
    
    	2) About a CHIPCOM Access Module for EMA/DECmcc plateform, there is
    not known agreement (to me...)... But there are some inhouse
    development of a "dummy AM" around DECmcc/TCPIP AM + CHIPCOM private
    MIB + EMM V2.1, development currently done by Dominique PACCO @BRO 
    (see note 3270.6)
    
    
    Regards,
    Renato
      
        

    RE: 3326.8  "NO Chipcom AM?"
    
    I think we're getting tangled up in the semantics...
    
    Let me take a stab at clarification:
    
    1. The Chipcom management DATA is currently accessible through the
       TCP/IP SNMP AM (after loading the CHIPCOM MIB using MTU).
    
    2. The structure of this data, when presented through the SNMP AM, 
       is a bit unwieldy. I heard mentioned that someone is writing an AM
       to restructure the data into a more sensible form (attributes with
       descriptive names, maybe a more rational entity model). This new AM
       actually calls the SNMP AM to get the raw data...
    
    3. "writing an AM" and "a graphical view of the hub" involves two
       different things: AMs provide data, PMs (or launched applications
       that have a PM component) provide hub pictures, LEDs that show red
       or green, switches that can be acted on, etc.  The DECmcc V1.2
       Iconic Map PM (IMPM) doesn't support hub graphics yet, but applications
       like Synoptic's Hub Manager and DEC's HubWatch (for DEChub90) which
       do will launch from the IMPM.
    
    4. I don't know if Chipcom has a graphical hub manager application that
       runs on VMS or ULTRIX. ANyone have more information on this?
    
    						Chris Brienen 
    

    
    Hi Chris,
    
    An aggreement has been done between CHIPCOM Corp. and DEC about
    integrating NCS CHIPCOM proprietary software (ONline Network Control
    System) in a DECmcc/MSU environment (please note the MSU-suffix...).
    
    Nowadays, I know from CHIPCOM themselves that NCS, after running on PC
    and SUN platform, has been adapted for ULTRIX/RISC DECstation 5000/xxx (I'm
    currently in contact with CHIPCOM about HW/SW platform
    characteristics). That adaptation seems to be done both by CHIPCOM
    Israel and CHIPCOM U.K.
    
    Note also that CHIPCOM doesn't currently know the status of a
    DECmcc/MSU integration of NCS, but they really seem to convince our
    common customers about their willing of opening to multi-vendor management
    platforms, particularly DEC's platforms.
    
    
    Renato