RE: Problem with defining custom data type (TEXTUAL-CONVENTION)

> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Manfred Wassmann
> Sent: Monday, January 21, 2008 2:52 PM

> TNX for your answer. I actually have at least two instances 
> of myVersion 
> but they have to have different access clauses, so I guess I 
> can't put 
> them into one table. I rewrote my MIB to define myVersionDigits and 
> myVersionState as seperate entities and it works so far. Yet 
> I wonder why 
> I can't combine them into a third entity like it is done in the 
> UCD-SNMP-MIB:
> 
> logMatchEntry OBJECT-TYPE
>          SYNTAX LogMatchEntry
> [...]
> LogMatchEntry ::=
>          SEQUENCE {
>                  logMatchIndex
>                          Integer32,
> [...]

	Also, and importantly (as I understand it):

<SNIP>
logMatchTable OBJECT-TYPE
	SYNTAX SEQUENCE OF LogMatchEntry
	MAX-ACCESS not-accessible
	STATUS current
	DESCRIPTION
		"Table of monitored files."
	::= { logMatch 2 }
</SNIP>

	...which tells us that LogMatchEntry is a table row and may therefore be a sequence.  To elaborate on Dave's earlier point, SNMP's SMI is not a full implementation of ASN.1.  Only table rows may be SEQUENCEs.

> This is accepted by smilint but when I try the following smilint tells
> me: "MY-MIB.txt:91: [2] type `MyCompoundVersion' of node
> `myVersionNumber' does not resolve to a known base type"

	Correct.  You defined it as a SEQUENCE.  It is not a table row, so therefore must be a base type.

	For a suggestion on how to solve your problem, check this from SNMPv2-TC:

<SNIP>
TDomain ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
          "Denotes a kind of transport service.

          Some possible values, such as snmpUDPDomain, are defined in
          the SNMPv2-TM MIB module.  Other possible values are defined
          in other MIB modules."
    REFERENCE    "The SNMPv2-TM MIB module is defined in RFC 1906."
    SYNTAX       OBJECT IDENTIFIER

TAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
          "Denotes a transport service address.

          A TAddress value is always interpreted within the context of a
          TDomain value.  Thus, each definition of a TDomain value must
          be accompanied by a definition of a textual convention for use
          with that TDomain.  Some possible textual conventions, such as
          SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
          MIB module.  Other possible textual conventions are defined in
          other MIB modules."
    REFERENCE    "The SNMPv2-TM MIB module is defined in RFC 1906."
    SYNTAX       OCTET STRING (SIZE (1..255))
</SNIP>

	These two objects are interlocked only by their definition - there is no way to enforce this in SMI.  MIBsmiths who wish to use this TC define objects of both types, one after the other, either as scalars or as columnar objects, depending on their need.


	HTH,

Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users