Home
You are not currently signed in.

MIB Smithy

  1. Up to Table of Contents

Querying Module Properties

Module records represent the highest-level structure of an actual MIB or PIB specification. It is a container record, like file records and databases, so it provides properties for heirarchical lists of the records defined within them. It also provides important properties for the specifications themselves, particularly for the IMPORTS, which specify the relationship between definitions of different modules such as types and layout of the OID tree.

Syntax:

% dbcmd get property ?property ...? module

Returns:

  • The value of the specified property or properties (see below).

Properties:

-capabilities

Returns a list of all AGENT-CAPABILITIES statements defined within the module.

cap1 cap2 cap3 ...

-cgroups

Like -cmodules, but each conformance module name is coupled with a list of all conformance groups (GROUP) defined within the conformance module of a MODULE-COMPLIANCE.

comp1 { MODULE1 { group1 group2 group3 ... } ... } ...

-cmodules

Like -capabilities and -compliances, but each conformance name is coupled with a list of all conformance modules (SUPPORTS/MODULE) defined within the conformance.

comp1 { MODULE1 MODULE2 ... } comp2 { MODULE1 MODULE2 ... } ...

-comments
Returns the textual comments associated with the module. When importing, any comments that are not associated with a record within the module, or a named-number enumeration, get assigned to the module.
-compliances

Returns a list of all MODULE-COMPLIANCE statements defined within the module.

comp1 comp2 comp3 ...

-container
Returns the fully-qualified name of the record in which the queried record is contained. This property equivalent to -fullname for the container record, or for the queried record with the last envelope stripped off.
-exportslist

Returns the list of symbols that are exported from the module (i.e., those that can be imported into another module, as in the EXPORTS section at the start of an ASN.1 module)). SMIv2 modules are forbidden to use the EXPORTS convention: all symbols are implicitly exported from such modules.

symbol1 symbol2 symbol3 ...

-fullname
Returns the fully-qualified name of the module in the form accepted by the SDK as a search query. For this record type, that is the file handle and the module name joined together with a ! (exclamation point), as in @File1!SNMPv2-MIB.
-fulloid
Returns the absolute (or as close as possible) OID value for the module (as defined in the ASN.1 module header) in dotted numeric notation (e.g. 1.3.6....). If the OID is not able to be resolved all the way to one of the root nodes (ccitt, iso, joint-iso-ccitt), due to one or more dependent modules not being present in the database, then the first component will be that of the descriptor that could not be resolved.
-groups
Returns a list of all OBJECT-GROUP and NOTIFICATION-GROUP records defined within the module.
-importslist
Returns the list of symbols imported into the module (as in the IMPORTS section at the start of an ASN.1 module). The result is a list of lists of the form: { symbolList moduleName ?oidvalue? }, where symbolList is a list of symbols to import from the module named moduleName and oidvalue is an optional object identifier value that unamibuously references the module (either assigned in the module header in ASN.1/SMIv1 modules or the value of an SMIv2/COPS-PR-SPPI module's MODULE-IDENTITY statement).
-members

Returns a list of all records that are immediate children of the module.

Type1 Type2 rec1 rec2 rec3 ...

-moduleids
Returns a list of all MODULE-IDENTITY statements defined within the module. For valid modules, this will be an empty string for SMIv1 modules and a single record for SMIv2 or COPS-PR-SPPI modules.
-name
Returns the unqualified name of the module as it appears in the ASN.1 module header. This option is mainly of use when querying the module by OID value rather than by name.
-ngroups

Returns a list of all NOTIFICATION-GROUP records defined within the module.

group1 group2 group3 ...

-notifications

Returns a list of all NOTIFICATION-TYPE and TRAP-TYPE records defined within the module.

trap1 trap2 trap3 ...

-objects

Returns a list of all OBJECT-TYPEs defined within the module.

obj1 obj2 obj3 ...

-ogroups

Returns a list of all OBJECT-GROUP records defined within the module.

group1 group2 group3 ...

-oid
Returns the OID value for the module (as defined in the ASN.1 module header), dot-delimited, with the module name and name portion of name-and-number forms (if any) stripped out. That is, a.1.2.3 will be returned even if the OID value is declared in the ASN.1 as { EX-MIB.a b(1) c(2) 3 }.
-oids

Returns a list of all record definitions that are immediate children of the module and assign or register an object identifier value, including various macro invocations and ASN.1 OID Value Assignments.

rec1 rec2 rec3 ...

-rootnodes
Returns the subset of -oids whose OID values place them in the OID tree above all other records within the same module (i.e., the subset whose parents are in defined in other modules). For example, if all OIDs in an SMIv2 module are defined subordinate to the MODULE-IDENTITY statement, then this option will return the name of that MODULE-IDENTITY.
-tags
Returns the configured value for the TagDefault parameter of the ASN.1 module header. Will either return EXPLICIT or IMPLICIT, with the former being the default.
-typedefs

Returns a list of all ASN.1 Type Assignments and TEXTUAL-CONVENTIONs defined within the module.

Type1 Type2 Type3 ...

-value
Equivalent to -oid for get operations.
-valuedecl
Returns the "as-declared" OID value for the module (as defined in the ASN.1 module header), dot-delimited. If the first component is specified using module.descriptor form it is returned as module:descriptor. That is, SNMPv2-MIB:system.1 will be returned if the OID value is declared in the ASN.1 it as { SNMPv2-MIB.system 1 }.
-values

Returns a list of all ASN.1 Value Assignments (other than OIDs) defined within the module.

rec1 rec2 rec3 ...

-variations

Like -cmodules, but each conformance module name is coupled with a list of all variations (OBJECT/VARIATION) defined within the conformance statement.

comp1 { MODULE1 { var1 var2 var3 ... } ... } ...

  1. Up to Table of Contents