| < Prev | Back to Table of Contents | Next > |
Variable Bindings
The varBindList parameter, which need not
be present, is used by the SNMP Request subcommands (get, set, next, and set) to specify each object
identifier, type, and value to be included in the transmitted PDU.
The value of the parameter is a list of
varBind parameters as follows:
?varBind ?varBind? ...?
Each varBind is its self a list that can
have 1, 2 or 3 parameters indicating the object identifier
(required), the value (optional) and, if necessary, the data type to
use when encoding the value. Accepted forms for
varBind are:
oid
oid value
oid type value
The oid parameter can be specified using
any of the values accepted by the SMI Database's get
subcommand specifying a query search string. That is, it could be an
identifier such as system, an absolute OID such as
1.3.6.1.2.1.1.1.0, a relative OID such as
sysDescr.0 or a multi-envelope search string such as
@File1!SNMPv2-MIB!sysDescr.0. The configured (or
specified) SMI Database will be queried, as necessary, to convert the
specified oid parameter to a fully-qualified OID
value.
The type parameter, if present, can also
be specified using either one of the fundamental SNMP data types
(such as INTEGER or OCTET STRING) or as a
defined datatype as with the SMI Database's get
subcommand query search string, such as RowStatus or
SNMPv2-TC!RowStatus. If the type
parameter is not present, or if it is not one of the fundamental SNMP
data types, then the configured (or specified) SMI Database will be
queried to determine the appropriate data type as necessary.
The valid values for the value depend on
the data type. Typically this must be the raw (unformatted) value,
such as an integer or a character or hex string. For OBJECT
IDENTIFIER values, the value specified may take the same forms as
those for the oid parameter: the SDK will automatically
convert the search specification into an absolute OID to send in the
message. For enumerated INTEGER values, versions 3.4 and later of the
SDK accept integer values, a label (such as 'destroy' for
RowStatus), or both a label and the integer value (such as
'destroy(6)').
The value may be specified for "read" operations (GET, GET-NEXT, GET-BULK) and, if specified, will be included in the PDU; however, properly implemented agents will ignore them in handling such requests.
In result list returned during a synchronous request call, or
passed to the args parameter of the callback
function, the -varbinds field indicates the variable
bindings in the response. The format for this field is the same as
that for requests, however all three parameters are present for each
variable binding.
Three special keywords may be present for the
value field when the
type field is NULL and the PDU
is encapsulated in an SNMPv2c or SNMPv3 message. These keywords
correspond to the three "exceptions" defined by the SNMPv2
PDUs (which are also used by SNMPv3), and they are:
endOfMibView, noSuchObject and
noSuchInstance.
Example 1 - GET/GET-NEXT/GET-BULK Request Forms:
% snmplib get 1.3.6.1.2.1.1.1.0
% snmplib get { { 1.3.6.1.2.1.1.1.0 } }
% snmplib get [list [list 1.3.6.1.2.1.1.1.0]]
% snmplib get [list sysContact.0 sysLocation.0]
% snmplib get [list SNMPv2-MIB!sysContact.0 SNMPv2-MIB!sysLocation.0]
% snmplib get [list [list 1.3.6.1.2.1.1.1.0 NULL NULL]]
Example 2 - SET Request Forms:
% snmplib set { { 1.3.6.1.2.1.1.4.0 "New Contact" } }
% snmplib set [list [list 1.3.6.1.2.1.1.4.0 "New Contact"]]
% snmplib set [list [list sysContact.0 DisplayString "New Contact"]]
% snmplib set [list [list sysContact.0 DisplayString "New Contact"] \
[list sysLocation.0 DisplayString "New Location"]]
Example 3 - endOfMibView Exception:
% array set result [snmplib next -version SNMPv2c 2.0]
% array get result -status
noError
% array get result -varbinds
-varbinds {{2.0 NULL endOfMibView}}
| < Prev | Back to Table of Contents | Next > |