Conference azur::mcc

RE: .0

> TYPE
>  ModuleSlotIndexType = 301
>    SEQUENCE SimpleName,Integer32;

  :

>  CHILD ENTITY chipcom_module_ethernet = 750 : 
>    PARENT     = ( SCRIPT ),
>    IDENTIFIER = ( Module Slot Index ),
>    DYNAMIC    = TRUE,
>
>    IDENTIFIER ATTRIBUTES
>
>      ATTRIBUTE Module Slot Index = 200 : ModuleSlotIndexType
>        ACCESS     = NONSETABLE,
>        DISPLAY    = TRUE,
>        CATEGORIES = ( CONFIGURATION )
>      END ATTRIBUTE Module Slot Index;
>
>    END ATTRIBUTES; (* IDENTIFIER *)

>   QUESTIONS : 
>    1) is my (<module>,<slot>) instance definition correct ?
>    2) is it possible to define such instance definition ?
>    3) is there any problem with my index datatypes (ie
>       SimpleName,Integer32) ? 

  Renato,

  I did not try the Instance Identifer as a conplex type .. I had
  only used the SimplName datatype .. so I'll guess that the
  Script AM doesn't like this.  Can you change this back to a
  SimpleName and retest?

  I am not sure if this type of Instance Identifier is even legal,
  Can anyone else verify this?

  /keith

    
    Keith,
    
    With SimpleName (or Latin1String), it works correctly.
    
    May I have any other opinion about my index definition ?
    
    Renato
    
    

RE: .2

>    With SimpleName (or Latin1String), it works correctly.

  Good 8)
    
>    May I have any other opinion about my index definition ?

  You mean like -- how can you get something like :

     TYPE
      ModuleSlotIndexType = 301
        SEQUENCE SimpleName,Integer32;

  to work?

  You could try using the Latin1String and put both parameters inside:

    create script .script.chipcom_procedures -
           chipcom_module_ethernet "(etoile1, 4)" -
    command="/usr/users/vista/mcc_scripts/chipcom_module_ethernet etoile1 4)"

  Or something along that line ... I didn't try this, so I'm not sure
  if it will work.

  btw - I think the problem with the Identifier Instance as a SEQUENCE
  is a DECmcc MIR problem.  The Script AM doesn't care what it is, it
  just writes the Identifier to the MIR.

  Can anyone verify if the MIR supports a SEQUENCE in an Instance Identifier?

  /keith

    
    Keith,
    
    This kind of SEQUENCE description seems to be used oftenly in *.ms got
    after translating ASN1 private MIB source files as following : 
    
    ... from *_mibdef.txt file ...
    
    olEnetStatsModTable OBJECT-TYPE
    	SYNTAX SEQUENCE OF OlEnetStatsModEntry
    	ACCESS not-accessible
    	STATUS mandatory
    	DESCRIPTION
    		"A table of statistical information counted for each module
    		in each Ethernet (IEEE 802.3) network."
    	::= { olEnet 2 }
    
    olEnetStatsModEntry OBJECT-TYPE
    	SYNTAX OlEnetStatsModEntry
    	ACCESS not-accessible
    	STATUS mandatory
    	DESCRIPTION
    		"A list of statistical information for each port
    		on each Ethernet (IEEE 802.3) network in the concentrator."
    	INDEX { olEnetStatsModNetID, olEnetStatsModSlotIndex }
    	::= { olEnetStatsModTable 1 }
    
    OlEnetStatsModEntry ::=
    	SEQUENCE {
    		olEnetStatsModNetID
    			INTEGER,
    		olEnetStatsModSlotIndex
    			INTEGER,
    		olEnetStatsModFramesRcvdOks
    			Counter,
    		olEnetStatsModOctetsRcvdOks
    			Counter,
    		olEnetStatsModMcastRcvdOks
    			Counter,
    		olEnetStatsModBcastRcvdOks
    			Counter,
    		olEnetStatsModFrameTooLongs
    			Counter,
    		olEnetStatsModAlignmentErrors
    			Counter,
    		olEnetStatsModFCSErrors
    			Counter,
    		olEnetStatsModRunts
    			Counter
    		}
    
    olEnetStatsModNetID OBJECT-TYPE
    	SYNTAX INTEGER {
    		ethernet-1(6), -- corresponds to ifIndex
    		ethernet-2(7),
    		ethernet-3(8)
    		}
    	ACCESS read-only
    	STATUS mandatory
    	DESCRIPTION
    		"The unique identifier for this network.  
    		One of ethernet-1, ethernet-2, or ethernet-3."
    	::= { olEnetStatsModEntry 1 }
    
    olEnetStatsModSlotIndex OBJECT-TYPE
    	SYNTAX INTEGER
    	ACCESS read-only
    	STATUS mandatory
    	DESCRIPTION
    		"The slot number that contains this module."
    	::= { olEnetStatsModEntry 2 }
    
    
    
    ... from *_mibdef.ms file ...
    
            CHILD ENTITY olEnetStatsModTable = 73 :
                IDENTIFIER = ( olEnetStatsModTable_Index),
                DYNAMIC = TRUE,
                SYMBOL = EN49_2_3_1_5_2_2,
    
              IDENTIFIER ATTRIBUTES
                ATTRIBUTE olEnetStatsModTable_Index   = 11 :
    						olEnetStatsModTableIndexType
                    ACCESS     = NONSETTABLE,
                    DISPLAY    = TRUE,
                    CATEGORIES = (CONFIGURATION),               
    		    SYMBOL = EN49_2_3_1_5_2_2_1_1_ID,
                    SNMP_OID = {1 3 6 1 4 1 49 2 3 1 5 2 2 1 1}
                END ATTRIBUTE olEnetStatsModTable_Index;
              END ATTRIBUTES;
    ...
    
    
              CHARACTERISTIC ATTRIBUTES
                ATTRIBUTE olEnetStatsModNetID   = 1 : olEnetStatsModNetID_enm
                    ACCESS     = NONSETTABLE,
                    DISPLAY    = TRUE,
                    CATEGORIES = (CONFIGURATION),
                    SYMBOL = EN49_2_3_1_5_2_2_1_1,
                    SNMP_OID = {1 3 6 1 4 1 49 2 3 1 5 2 2 1 1}
                END ATTRIBUTE olEnetStatsModNetID;
                ATTRIBUTE olEnetStatsModSlotIndex   = 2 : Integer32
                    ACCESS     = NONSETTABLE,
                    DISPLAY    = TRUE,
                    CATEGORIES = (CONFIGURATION),
                    SYMBOL = EN49_2_3_1_5_2_2_1_2,
                    SNMP_OID = {1 3 6 1 4 1 49 2 3 1 5 2 2 1 2}
                END ATTRIBUTE olEnetStatsModSlotIndex;
              END ATTRIBUTES;
    
    ... from *_mibdef_enum.ms file ...
    
    TYPE
      olEnetStatsModNetID_enm = 236 (
        ethernet_1 = 6,
        ethernet_2 = 7,
        ethernet_3 = 8);
    
    ...
    
    TYPE
      olEnetStatsModTableIndexType = 302
        SEQUENCE olEnetStatsModNetID_enm,Integer32;
    ...
    
    
    
    Any opinion about this definition ?
    
    Renato
    

I believe that the DECmcc instance MIR will support only primitive 
data types, i.e.; not constructed data types, for identifiers.

So, SEQUENCE, SET, SEQUENCE OF, SET OF, RECORD, VARIANT RECORD, AES,
etc. are not supported for identifiers.  You can check the SRM, Chapter
9, and if the data type you are interested in is listed in the
constructed types or is similar in form, you may not use it as an 
identifier.

You are safest to use string, integer, fullname, simplename.  (however, 
remember fullname is only appropriate for global entities.) 

...kjn

    You can't use constructed datatypes as identifiers in an instance
    repository.   The reason is that they must be able to function as "key"
    fields in the database sense, and the semantics for searching and
    ordering are radically different for each type of constructor, and in
    fact are not even defined for some types.
    
    For example, SET {1,2,3} should match SET {3,2,1} in a lookup, but if
    the type were SEQUENCE, they would not match.
    
    You would need a unique MCC software emulation of lookup by key for
    each type (scalar types can be looked up by the underlying database
    directly).  Those that already complain about the size and speed of MCC 
    should realize the implications of this requirement.
    
    I'm not trying to make excuses - just pointing out that it's a
    conscious design decision and not a bug.

    
    To .5 & .6,
    
    Thank you for your replies. May I have your opinions about the ASN1
    description (related to a private MIB with <I,J> instances based on
    such indices described as Identifier Attributes ) ?
    
    Renato
    
    

> I believe that the DECmcc instance MIR will support only primitive 
> data types, i.e.; not constructed data types, for identifiers.

I am not arguing with this decision but would like some clarification.  Does
that  mean the DECmcc cannot manage a subentity which has a constructed type
as  an  identifier? Or is the restriction weaker (like, maybe, the historian
doesn't work for them, or something)?

Personally I  hate such things (and the LES NM code cannot cope with them in
general  either!).   However,  there  is  an important subentity which has a
record  as  an  identifier:  NODE, ROUTING, IP DESTINATION ADDRESS.  Can MCC
display  that?  (In the LES NM code there is a very specific *hack* for this
particular entity!).

> You are safest to use string, integer, fullname, simplename.  (however, 
> remember fullname is only appropriate for global entities.) 

Eh? Fullname  is  appropriate  for  subentities as well.  I can think of one
entity  straight  away  that  has a FullName as an identifier (NODE, SESSION
CONTROL,  KNOWN  TOWER) and I am sure there are others.  Is there some other
restriction  here  or  had  you just not realised that FullNames are used as
subentity identifiers?

Graham

You will have to check with the MCC MIR folks to get the exact rundown 
on constructed types as identifiers.  Some of it has to do with 
restrictions on storage, for example relational databases cant handle 
constructed types at all (Exporter limitation).  Some other restrictions 
have to do with key lookups and valid datatypes for those.

As far a fullname goes.  I was mostly making a statement about 
philosophy.  I support a lot of third parties in their efforts to write 
management modules that plug into DECmcc.  They tend to take the 
examples to the extreme as the documentation is not always clear. They 
tend to try to make child entity identifiers of datatype Fullname
and/or Simplename. 

Why use an opaque type when a simple string will do?  Why make more work 
for yourself and confuse the user with dots and namespace names in front
of the actual name? 

The purpose of a fullname is to name the path in the naming service that
makes the name of this instance unique.  The simplename datatype is just 
a portion of the fullname that specifies a stop along the naming path, 
the rightmost simplename of the fullname is of course referred to as the 
local name.
 
Naming services (at least DNS) only know how to deal with the globally
addressable things, which (for the most part) tend to be global
entities.  Take, for example, Line SVA-0 on Node4 KAJUN. It doesn't make
any sense to give the Line a fullname identifier, as it is the parent
hierarchy NODE4 KAJUN LINE SVA-0 that gives the line its unique name. 

There are other child entities that represent relationships to other 
entities and so are named the name of the entity on the other end of the 
relationship. (whew!)  In this case it might make sense for the child to 
take on a fullname datatype for its identifier IF the entity on the 
other end of the relationship is a global entity.

just my soapbox, 
...kjn