Status in source: current.
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"ups29AlarmTable",
"OBJECT-TYPE",
"SYNTAX",
"SEQUENCE",
"OF",
"Ups29AlarmEntry",
"MAX-ACCESS",
"not-accessible",
"STATUS",
"current",
"DESCRIPTION",
"\"A list of alarm table entries. The table contains zero, one, or many rows at any moment, depending upon the number of alarm conditions in effect. The table is initially empty at agent startup. The agent creates a row in the table each time a condition is detected and deletes that row when that condition no longer pertains. The agent creates the first row with ups29AlarmId equal to 1, and increments the value of ups29AlarmId each time a new row is created, wrapping to the first free value greater than or equal to 1 when the maximum value of ups29AlarmId would otherwise be exceeded. Consequently, after multiple operations, the table may become sparse, e.g., containing entries for rows 95, 100, 101, and 203 and the entries should not be assumed to be in chronological order because ups29AlarmId might have wrapped. Alarms are named by an AutonomousType (OBJECT IDENTIFIER), ups29AlarmDescr, to allow a single table to reflect well known alarms plus alarms defined by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. No two rows will have the same value of ups29AlarmDescr, since alarms define conditions. In order to meet this requirement, care should be taken in the definition of alarm conditions to insure that a system cannot enter the same condition multiple times simultaneously. The number of rows in the table at any given time is reflected by the value of ups29AlarmsPresent.\"",
"::=",
"{",
"ups29Alarm",
"2",
"}"
],
"syntax_tree": [
[
"conceptualTable",
[
"row",
"Ups29AlarmEntry"
]
],
null,
[
"MaxAccessPart",
"not-accessible"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"A list of alarm table entries. The table contains zero, one, or many rows at any moment, depending upon the number of alarm conditions in effect. The table is initially empty at agent startup. The agent creates a row in the table each time a condition is detected and deletes that row when that condition no longer pertains. The agent creates the first row with ups29AlarmId equal to 1, and increments the value of ups29AlarmId each time a new row is created, wrapping to the first free value greater than or equal to 1 when the maximum value of ups29AlarmId would otherwise be exceeded. Consequently, after multiple operations, the table may become sparse, e.g., containing entries for rows 95, 100, 101, and 203 and the entries should not be assumed to be in chronological order because ups29AlarmId might have wrapped. Alarms are named by an AutonomousType (OBJECT IDENTIFIER), ups29AlarmDescr, to allow a single table to reflect well known alarms plus alarms defined by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. No two rows will have the same value of ups29AlarmDescr, since alarms define conditions. In order to meet this requirement, care should be taken in the definition of alarm conditions to insure that a system cannot enter the same condition multiple times simultaneously. The number of rows in the table at any given time is reflected by the value of ups29AlarmsPresent."
],
null,
null,
null,
null
]
}