Hypercom 1101 User Manual

Page of 106
SNMP Usage
92
Hypercom Corporation
SNMP Usage
SNMP requests act on a variable-per-variable basis. However, in most cases, you will want to 
modify multiple variable first, then after all the changes are done, submit the whole configuration 
and apply all of the changes at the same time. To accomplish this, the following provisions were 
made:
SNMP Get requests are served from the actual configuration the device is using
SNMP Set requests are cached by the SNMP agent and retained until the configuration is 
committed
An additional MIB variable is included in the System Configuration group to let the user control 
the edition operation. The variable name is configEditionControl and its possible values are:
- noAction
- editing
- applyCfgChanges
- discardCfgChanges
Changing a Configuration
To begin a configuration change, you can modify a variable in the System Configuration group. 
The SNMP agent automatically changes the configEditionControl value to “editing”. A timer starts 
to give you a period of time to use the SNMP interface for configuration changes. This expires 
after 30 minutes of no activity. A detailed explanation of this timeout feature is described below.
Another possibility is to manually set the configEditionControl value to “editing” before changing 
any other variable. The resulting behavior is the same.
Once an edition has started, you can modify as many variables as needed. When all of the 
changes have been made, set the configEditionControl value to “applyCfgChanges”. This tells 
the SNMP agent to validate the cached configuration and, if successful, commit it to flash.
Before committing a configuration to flash, it is validated. If correct, it is saved and the device 
resets. If there is a problem with the validation, the MIB variable “lastSNMPError” contains the 
error code and the MIB variable “lastSNMPErrorString” contains the corresponding error 
message. You can obtain these values using SNMP Get requests. The SNMP agent keeps the 
cached configuration in memory, so you can review and fix the problem, then try to commit again.
time-stamp
The time between the last initialization of the network entity that issued the trap 
and the generation of the trap.
variable_bindings
Additional implementation-specific information relating to the trap.
Field
Description