FSC-HPI-MIB: View SNMP OID List / Download MIB

The interface version is the version of the actual interface and not the version of the implementation. It is a 24 bit value where the most significant 8 bits represent the compatibility level (with letters represented as the corresponding numbers); the next 8 bits represent the major version number; and the least significant 8 bits represent the minor version number.

The Agent Implementation Version

This columnar node provides the Resource Id of the domain the HPI-MIB SNMP implementation is running on. This is to help prevent powering down the machine providing the SNMP service.

This columnar node forces the discovery of all resources and associated domains by the underlying management service.

The Status of the HPI Resource Discovery. Enumeration: 'start': 1, 'stopped': 4, 'done': 3, 'undefined': 0, 'working': 2.

The time in seconds needed for Discovery

The time in seconds between two HPI Resource Discoveries. A value of 0 means 'no auto discovery'.

The number of Domain entries present in the system.

This table represents the management attributes common to all Domains within the managed platform. The logical domain ID and the entity ID are used to address an entity.

Domain Info: This structure is used to store the information regarding the domain including information regarding the domain reference table (DRT) and the resource presence table (RPT). The DomainTag field is an informational value that supplies an HPI User with naming information for the domain. NOTE: Regarding timestamps - If the implementation cannot supply an absolute timestamp, then it may supply a timestamp relative to some system-defined epoch, such as system boot. The value SAHPI_TIME_UNSPECIFIED indicates that the time of the update cannot be determined. Otherwise, If the value is less than or equal to SAHPI_TIME_MAX_RELATIVE, then it is relative; if it is greater than SAHPI_TIME_MAX_RELATIVE, then it is absolute. The GUID is used to uniquely identify a domain. A GUID value of zero is not valid and indicates that the domain does not have an associated GUID.

The SAHPI_UNSPECIFIED_DOMAIN_ID value is used to specify the default domain. SAHPI_UNSPECIFIED_DOMAIN_ID 0xFFFFFFFF(4294967295)

This definition defines the capabilities of a given domain. A domain may support any number of capabilities. autoinsertReadOnly Indicates that the domain auto insert timeout value is read-only and may not be modified using the hpiHotSwapAutoInsertTimeoutSet columnar object.

Indicates that this domain participates in a peer relationship. true = Domain is peer. false = Domain is not peer.

Information tag associated with domain. See Definition for SaHpiTextType for more details.

Information tag associated with domain. See Definition for SaHpiTextLanguage for more details.

Information tag associated with domain. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

This count is incremented any time the table is changed. It rolls over to zero when the maximum value (2^32) is reached.

This timestamp is set any time the DRT table is changed. Refer to SaHpiTime for full description.

This count is incremented any time the RPT is changed. It rolls over to zero when the maximum (2^32) value is reached

This timestamp is set any time the RPT table is changed. Refer to SaHpiTime for full description.

This count is incremented any time the DAT is changed. It rolls over to zero when the maximum value (2^32) is reached

This timestamp is set any time the DAT is changed. Refer to SaHpiTime for full description.

Count of active alarms in the DAT.

Count of active critical alarms in the DAT.

Count of active major alarms in the DAT.

Count of active minor alarms in the DAT.

Maximum User Alarms that can be added to DAT. 0 = no fixed limit.

Set to True if there are one or more non-User Alarms that are missing from the DAT because of space limitations.

The GUID is used to uniquely identify a domain. A GUID value of zero is not valid and indicates that the domain does not have an associated GUID. GUID - Globally Unique Identifier The format if the ID follows that specified by the Wired for Management Baseline, Version 2.0 specification. HPI uses version 1 of the GUID format, with a 3-bit variant field of 10x (where x indicates 'don't care')

The number of DRT entries present in the hpiDomainReferenceTable.

A table, provided by an HPI implementation, of additional domains related to the current domain.

The Domain Reference Table (DRT) which provides information about other domains associated with the domain. The two hpiDomainId are used to uniquely identify a domain and a corresponding domain which can be off peer or tiered domain architecture. The DRT contains an entry for each associated domain, and HPI MIB Users may read these entries to discover the presence of additional domains within a 'System'. The discovered domains can, in turn, be used to discover additional resources and domains. The DRT is automatically built and maintained by the HPI implementation. Domain entries in the DRT may change over time if the 'System' configuration changes. There are two types of domain references: - A peer domain architecture, which consists of two or more domains that are expected to contain the same resources and domain references. Each domain in a peer relationship contains an RPT listing all resources present in each domain. - A tiered (child) domain architecture is used when all the resources in a'system' cannot be accessed in a single domain. A 'parent' domain references one or more 'child' domains in its DRT. The 'child' domains may be simple domains containing only resources, or they may themselves be a 'parent' to other 'child' domains. Domains in a tiered relationship are disjointed and do not contain the same resources. Note: When a domain is added to the DRT (SAHPI_DOMAIN_REF_ADDED) and when a domain is removed from the DRT (SAHPI_DOMAIN_REF_REMOVED) an event is generated.

Indicates that this domain participates in a peer relationship. true = Domain is peer. false = Domain is not peer (is a child)

The number of DomainAlarm entries present in the system.

This table represents the management attributes common to all Domains within the managed platform. The logical domain ID and the entity ID are used to address an entity.

This table is used to store alarm information.

DomainAlarm Id

Time when alarm was added to the DAT table. Refer to SaHpiTime for full description.

Severity of alarm. (Only used with DAT and Annunciator functions. This is not a valid severity for events or alarms) Note: Enumerated values are increased by one value compared to SAI-HPI-B spec.

An HPI User acknowledges an alarm to indicate that it is aware of the alarm and to influence platform-specific alarm annunciation that may be provided by the implementation. Typically, an implementation ignores acknowledged alarms when announcing an alarm on annunciation devices such as audible sirens and dry contact closures. However, alarm annunciation is implementation-specific. An acknowledged alarm will have the Acknowledged field in the alarm entry set to True. DomainAlarms are acknowledged by one of two ways: a single alarm entry by DomainAlarmId regardless of severity or as a group of alarm entries by Severity regardless of DomainAlarmId. To acknowledge all alarms contained within the DAT, set the Severity parameter to allSeverities(256), and set the DomainAlarmId parameter to SAHPI_ENTRY_UNSPECIFIED. To acknowledge all alarms of a specific severity contained within the DAT, set the Severity parameter to the appropriate value, and set the DomainAlarmId parameter to SAHPI_ENTRY_UNSPECIFIED. To acknowledge a single alarm entry, set the DomainAlarmId parameter to a value other than SAHPI_ENTRY_UNSPECIFIED. The DomainAlarmId must be a valid identifier for an alarm entry present in the DAT at the time of the function call. If an alarm has been previously acknowledged, acknowledging it again has no effect. However, this is not an error. If the DomainAlarmId parameter has a value other than SAHPI_ENTRY_UNSPECIFIED, the Severity parameter is ignored. If the DomainAlarmId parameter is passed as SAHPI_ENTRY_UNSPECIFIED, and no alarms are present that meet the requested Severity, this function will have no effect. However, this is not an error. SAHPI_ENTRY_UNSPECIFIED is defined as the same value as SAHPI_FIRST_ENTRY, so using either symbol will have the same effect. However, SAHPI_ENTRY_UNSPECIFIED should be used with this function for clarity.

Enumeration of status condition type. This is read-only because creation is allowed for user Alarms only

Entity assoc. with status condition: If resource manages a FRU, entity path of the FRU. If resource manages a single entity, entity path of that entity. If resource manages multiple entities, the entity path of the 'primary' entity managed by the resource. Must be set to the same value in every domain which contains this resource. This object converts HPI's hpiEntityPathT structure and an OpenHPI canonical string. The canonical string is formed by removing the SAHPI_ENT_ prefix from the HPI types, and creating tuples for the entity types. Order of significance is inverted to make entity paths look more like Unix directory structure. It is also assumed that {ROOT,0} exists implicitly before all of these entries. For example: {SYSTEM_CHASSIS,2}{PROCESSOR_BOARD,0}

Sensor associated with status Only valid if Type is SAHPI_STATUS_COND_TYPE_SENSOR. This is read-only because creation is allowed for user Alarms only

Sensor event state. Only valid if hpiDomainAlarmCondType is sensor(1). This is read-only because creation is allowed for user Alarms only

AIS compatible identifier associated with Status condition. The Service Availability(TM) Forum Application Interface Specification standardizes the interface between Service Availability(TM) Forum compliant High Availability (HA) middleware and service applications. http://www.saforum.org

Manufacturer Id associated with status condition, required when hpiDomainAlarmCondStatusCondType is oem(3).

Optional data associated with status condition. For more details, see textual definition

Optional data associated with status condition. For more details, see textual definition

Optional data associated with status condition. The type of date is specified by hpiDomainAlarmCondDomainAlarmaTextType and hpiDomainAlarmCondDomainAlarmaTextLanguage.

This columnar node contains the status of the row and also perform add and delete operations. Enumeration: 'active': 1, 'toDelete': 3, 'toCreate': 2, 'undefined': 0.

The number of RPT entries present in the system. This field is used to determine if new resources have been added or existing removed.

The logical domain ID and the entity ID are used to address an entity.

This structure is used to store the RPT entry information. The ResourceCapabilities field definies the capabilities of the resource. This field must be non-zero for all valid resources. The ResourceTag field is an informational value that supplies the caller with naming information for the resource. This should be set to the user-visible name for a resource, which can be used to identify the resource in messages to a human operator. For example, it could be set to match a physical printed label attached to the primary entity which the resource manages. See section 5.2.6, SaHpiResourceTagSet(), on page 33.

Resource identifier. The SAHPI_UNSPECIFIED_RESOURCE_ID value is used to specify the Domain Event Log and to specify that there is no resource for such things as HPI User events/alarms. Note: SAHPI_UNSPECIFIED_RESOURCE_ID 0xFFFFFFFF

experimental

If resource manages a FRU, entity path of the FRU. If resource manages a single entity, entity path of that entity. If resource manages multiple entities, the entity path of the 'primary' entity managed by the resource. Must be set to the same value in every domain which contains this resource. This object converts HPI's hpiEntityPathT structure and an OpenHPI canonical string. The canonical string is formed by removing the SAHPI_ENT_ prefix from the HPI types, and creating tuples for the entity types. Order of significance is inverted to make entity paths look more like Unix directory structure. It is also assumed that {ROOT,0} exists implicitly before all of these entries. For example: {SYSTEM_CHASSIS,2}{PROCESSOR_BOARD,0}

Resource Capabilities This definition defines the capabilities of a given resource. One resource may support any number of capabilities using this string (each capability is seperated by a delimeter). Because each entry in an RPT will have the RESOURCE string, no value is not a valid value for the capability flag, and is thus used to indicate 'no RPT entry present' in some function calls. RESOURCE EVT_DEASSERTS Indicates that all sensors on the resource have the property that their Assertion and Deassertion event enable flags are the same. That is, for all event states whose assertion triggers an event, it is guaranteed that the deassertion of that event will also trigger an event. Thus, an HPI User may track the state of sensors on the resource by monitoring events rather than polling for state changes. AGGREGATE_STATUS CONFIGURATION MANAGED_HOTSWAP Indicates that the resource supports the full managed hot swap model. Since hot swap only makes sense for field-replaceable units, the FRU capability string must also be set for this columnar object. WATCHDOG CONTROL FRU Indicates that the resource is a field-replaceable unit; i.e., it is capable of being removed and replaced in a live system. If MANAGED_HOTSWAP is also set, the resource supports the full hot swap model. If MANAGED_HOTSWAP is not set, the resource supports the simplified hot swap model. ANNUNCIATOR POWER RESET INVENTORY_DATA EVENT_LOG RDR Indicates that a resource data record (RDR) repository is supplied by the resource. Since the existence of an RDR is mandatory for all management instruments, this capability must be asserted if the resource contains any sensors, controls, watchdog timers, or inventory data repositories. SENSOR

Indicates the criticality that should be raised when the resource is not responding. Note: The enumerated named have +1 added as opposed to the SA HPI spec for the same constants.

true = Resource Not Functional. false = Resource Functional

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource probvides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information that the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

hpiResourceInfo contains static configuration data concerning the management controller associated with the resource, or the resource itself. Note this information is used to describe the resource; that is, the piece of infrastructure which manages an entity (or multiple entities) - NOT the entities for which the resource provides management. The purpose of the hpiResourceInfoT structure is to provide information That the HPI user may need in order to interact correctly with the resource (e.g., recognize a specific management controller which may have defined OEM fields in sensors, OEM controls, etc. All of the fields in the following structure may or may not be used by a given resource.

GUID - Globally Unique Identifier The format if the ID follows that specified by the Wired for Management Baseline, Version 2.0 specification. HPI uses version 1 of the GUID format, with a 3-bit variant field of 10x (where x indicates 'don't care')

See Definition.

See Definition.

Resource tag. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

Resource tag. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

This object allows the user to save and restore parameters associated with a specific resource. Valid actions for this function include: undefined(0) - resource has no concept of configurations. restoreDefaultParm(1) - Restores the factory default settings for a specific resource. Factory defaults include sensor thresholds and configurations, and resource- specific configuration parameters. savaParm(2) - Stores the resource configuration parameters in non-volatile storage. Resource configuration parameters stored in non-volatile storage will survive power cycles and resource resets. restoreParm(3) - Restores resource configuration parameters from non-volatile storage. Resource configuration parameters include sensor thresholds and sensor configurations, as well as resource-specific. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'default': 1, 'restore': 3, 'save': 2, 'undefined': 0.

This function gets the reset state of an entity, allowing the HPI User to determine if the entity is being held with its reset asserted. If a resource manages multiple entities, this function will address the entity which is identified in the RPT entry for the resource. coldReset(1) and warmReset(2) are pulsed resets, and are not valid values to be returned in hpiResetAction. If the entity is not being held in reset (using resetAssert(3)), the appropriate value is resetDeAssert(4). Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'undefined': 0, 'coldReset': 1, 'deassert': 4, 'warmReset': 2, 'unsupported': 5, 'assert': 3.

This function gets the power state of an entity, allowing the HPI User to determine if the entity is currently powered on or off. If a resource manages multiple entities, this function will address the entity which is identified in the RPT entry for the resource. cycle(3) is a pulsed power operation and is not a valid return for the power state. This function controls the hardware power on a FRU entity regardless of what hot-swap state the resource is in. For example, it is legal (and may be desirable) to cycle power on the FRU even while it is in ACTIVE state in order to attempt to clear a fault condition. Similarly, a resource could be instructed to power on a FRU even while it is in INACTIVE state, for example, in order to run off-line diagnostics. Not all resources supporting hot swap will necessarily support this function. In particular, resources that use the simplified hot swap model may not have the ability to control FRU power. This function may also be supported for non-FRU entities if power control is available for those entities. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'on': 2, 'off': 1, 'undefined': 0, 'unsupported': 4, 'cycle': 3.

In support of hpiAutoInsertTimeoutGet(), hpiAutoInsertTimeoutSet()

Table of domains with a timeout for how long to wait before the default auto-insertion policy is invoked on a resource within a specific domain.

This function allows the HPI SNMP Manager to configure a timeout for how long to wait before the default auto-insertion policy is invoked on a resource within a specific domain. This columnar node accepts a parameter instructing each resource to impose a delay before performing its default hot swap policy for auto-insertion. The parameter may be set to SAHPI_TIMEOUT_IMMEDIATE ( see SaHpiTime Textual-Convention for further details) to direct resources to proceed immediately to auto-insertion, or to SAHPI_TIMEOUT_BLOCK ( see SaHpiTime Textual-Convention for further details) to prevent auto-insertion from ever occurring. If the parameter is set to another value, then it defines the number of nanoseconds between the time a hot swap event with hpiHotSwapState == insertionPending(5) is generated, and the time that the auto-insertion policy will be invoked for that resource. If, during this time period, a hpiHotSwapPolicyCancel function call is processed, the timer will be stopped, and the auto-insertion policy will not be invoked. Each domain maintains a single auto-insert timeout value and it is applied to all contained resources upon insertion, which support managed hot swap. Once the auto-insertion process begins, the HPI SNMP Manager will not be allowed to take control of the insertion process; hence, the timeout should be set appropriately to allow for this condition. Note that the timeout period begins when the hot swap event with hpiHotSwapState == insertionPending(5) is initially generated.

The number of HotSwap entries present in the system.

This table represents management attributes common to all hot swappable resources in the managed platform. The entries in this table are straight from the HPI spec. This table builds upon information present in the hpiResourceTable.

An entry describing a particular hot swappable entity.

A FRU associated with a hot-swappable resource may include a hot swap indicator such as a blue LED. This indicator signifies that the FRU is ready for removal. This columnar node allows the HPI SNMP Manager to retrieve and set the state of this indicator. When retrieving the values, the valid states are either hpiHotSwapIndicator == off(1) or hpiHotSwapIndicator == on(2). This columnar node will return information, regardless of what hot swap state the resource is in. When setting the values, valid states include hpiHotSwapIndicator == off(1) or hpiHotSwapIndicator == on(2). This function will set the indicator regardless of what hot swap state the resource is in, though it is recommended that this function be used only in conjunction with moving the resource to the appropriate hot swap state. Enumeration: 'on': 2, 'off': 1, 'undefined': 0.

Refer to the textual convention for full details.

This function allows the HPI User to configure a timeout for how long to wait before the default auto-extraction policy is invoked. This function accepts a parameter instructing the resource to impose a delay before performing its default hot swap policy for auto-extraction. The parameter may be set to SAHPI_TIMEOUT_IMMEDIATE to direct the resource to proceed immediately to auto-extraction, or to SAHPI_TIMEOUT_BLOCK to prevent auto-extraction from ever occurring on a resource. If the parameter is set to another value, then it defines the number of nanoseconds between the time a hot swap event with hpiHotSwapState = extractionPending(5) is generated and the time that the auto-extraction policy will be invoked for the resource. If, during this time period, a hpiHotSwapPolicyCancel function call is processed, the timer will be stopped, and the auto-extraction policy will not be invoked. Once the auto-extraction process begins, the HPI User will not be allowed to take control of the extraction process; hence, the timeout should be set appropriately to allow for this condition. Note that the timeout period begins when the hot swap event with hpiHotSwapState = extractionPending(4) is initially generated.

A resource supporting hot swap typically requires a physical action on the associated FRU to invoke an insertion or extraction process. An insertion process is invoked by physically inserting the FRU into a chassis. Physically opening an ejector latch or pressing a button invokes the extraction process. This columnar node allows the HPI User to invoke an insertion or extraction process via software. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'extraction': 2, 'undefined': 0, 'insertion': 1.

A resource supporting hot swap typically supports default policies for insertion and extraction. On insertion, the default policy may be for the resource to turn the associated FRU~s local power on and to de-assert reset. On extraction, the default policy may be for the resource to immediately power off the FRU and turn on a hot swap indicator. This function allows an HPI User, after receiving a hot swap event with hpiHotSwapState equal to INSERTION_PENDING or EXTRACTION_PENDING, to prevent the default policy from being executed. Once the resource transitions to either the ACTIVE or INACTIVE state, the default policies will once again execute, unless cancelled using hpiHotSwapPolicyCancel. The default policy cannot be canceled once it has begun to execute. Because a resource that supports the simplified hot swap model will never transition into INSERTION PENDING or EXTRACTION PENDING states, this function is not applicable to those resources. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'cancel': 1, 'undefined': 0.

Depending on the values, the user can: - use this function to request a resource to return to the ACTIVE state from the EXTRACTION PENDING state in order to reject an extraction request. Because a resource that supports the simplified hot swap model will never transition into INSERTION PENDING or EXTRACTION PENDING states, this function is not applicable to those resources. - use this function to request a resource to return to the INACTIVE state from the INSERTION PENDING state to abort a hot-swap insertion action. Because a resource that supports the simplified hot swap model will never transition into INSERTION PENDING or EXTRACTION PENDING states, this function is not applicable to those resources. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'setInActive': 2, 'undefined': 0, 'setActive': 1.

The number of events present in this table. hpiEventCount represents the total of types currently in the system. hpiDomainEventCount represents the subset of events that are Domain events. The same relationship exists for ResourceEvent, SensorEvent, SensorEnableChangeEvent, HotSwapEvent, WatchdogEvent, HpiSwEvent, OemEvent, UserEvent.

Event Master table.

This table presents the list of all events which are present in the HPI system. The implementation decides how to manipulate the events as they reach a large number. This table is used as a master event table which an index that points to the specific sub-table which has more details on the event. Each time a new event is surfaced in the HPI system this table increases by a new row and its respective sub-event table too (hpiResourceEventTable, hpiOEMEventTable, etc). Futhermore based on the type of event, an notification is generated as well.

Severity of event. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'major': 2, 'ok': 5, 'undefined': 0, 'critical': 1, 'debug': 241, 'informational': 4, 'minor': 3.

Refer to textual convention for SaHpiTime for more details. The value is Equal to TIME_UNSPECIFIED if time is not available; Absolute time if greater than TIME_MAX_RELATIVE, Relative time if less than or equal to TIME_MAX_RELATIVE.

Enumeration: 'unspecified': -1.

Refer to textual convention for SaHpiTime for more details. The value is Equal to TIME_UNSPECIFIED if time is not available; Absolute time if greater than TIME_MAX_RELATIVE, Relative time if less than or equal to TIME_MAX_RELATIVE.

Event type. Note: The enumerated named have +1 added as opposed to the SA HPI spec for the same constants. Enumeration: 'domain': 2, 'resource': 1, 'undefined': 0, 'hpiSw': 7, 'user': 9, 'oem': 8, 'watchdog': 6, 'hotswap': 5, 'sensor': 3, 'sensorEnableChange': 4.

This columnar node represents the subset of events that are Resource Events.

Event table.

Resource events.

Resource events are sent to indicate the failure or subsequent restoration of a resource. Resource events can also be used to announce the addition of a non-FRU resource to the RPT table. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'resourceRestored': 2, 'resourceAdded': 3, 'undefined': 0, 'resourceFailure': 1.

hpiDomainEventEntryCount represents the subset of events that are Domain events.

Event table.

Domain events.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT. Enumeration: 'domainRefRemoved': 2, 'undefined': 0, 'domainRefAdded': 1.

Domain Id of domain added to or removed from DRT.

This columnar node represents the subset of events that are Sensor Events.

Event table.

Sensor events.

Refer to the textual convention for more details.

Event category: See TEXTUAL-CONVENTION, SaHpiEventCategory.

Sensor Events and Sensor Event States: Each Event State may be asserted or deasserted. The set of Event States a sensor may support is defined by the sensor's 'Event Category.' A particular sensor, however, does not have to support all the Event States defined for its event category. The specific Event States that a particular sensor supports are indicated in the 'Events' field in the sensor's RDR. A sensor is not required to support any Event States. If no Event States are supported by a sensor, the 'Events' field will be 0x0000. A sensor may not support any Event States that are not defined for its event category. Each Event State is independent, although in some event categories the meaning assigned to the Event States will imply that certain Event States will be mutually exclusive. For example, a sensor that uses the SAHPI_EC_LIMIT event category should only have one of the two Event States, SAHPI_ES_LIMIT_NOT_EXCEEDED or SAHPI_ES_LIMIT_EXCEEDED asserted at any one time. Except where mutual exclusion is implied, however, sensors may have multiple Event States asserted simultaneously. For example, the event category SAHPI_EC_THRESHOLD uses six different event states to report the relationship between the value currently measured by the sensor and up to six different 'threshold' values. Each threshold is independently examined, and each Event State that represents a threshold that has been 'crossed' will be asserted. Threshold values must be configured so that 'Minor', 'Major' and 'Critical' thresholds are increasingly extreme readings, such that when a 'Major' threshold has been crossed, the corresponding 'Minor' threshold will also have been crossed, and thus both Event States will be asserted. When a sensor Event State is asserted or deasserted, an event may be generated by the resource. The generated event identifies the sensor and the event state being asserted or deasserted. The HPI implementation may assign event severity levels for each event state assertion or deassertion on an individual sensor basis.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to SaHpiEventState textual convention for more details.

Reserved for OEM use.

This columnar node represents the subset of events that are Sensor Enable ChangeEvents.

Event table.

Sensor Enable Change events.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Current sensor enable status.

Current event enable status.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Current set of asserted Event states.

This columnar node represents the subset of events that are HotSwap Events.

Event table.

Hot Swap events.

Refer to the textual convention for full details.

Refer to the textual convention for full details.

This columnar node represents the subset of events that are Watchdog Events.

Event table.

Watchdog events.

These enumerations represent the possible actions to be taken upon watchdog timer timeout and the events that are generated for watchdog actions. Enumeration: 'reset': 2, 'powerCycle': 4, 'powerDown': 3, 'noAction': 1, 'timerInt': 9, 'undefined': 0.

These enumerations represent the possible types of interrupts that may be triggered by a watchdog pre-timer event. The actual meaning of these operations may differ depending on the hardware architecture.

Watchdog Timer Use These enumerations represent the possible watchdog users that may have caused the watchdog to expire. For instance, if watchdog is being used during power on self test (POST), and it expires, the SAHPI_WTU_BIOS_POST expiration type will be set. Most specific uses for Watchdog timer by users of HPI should indicate SAHPI_WTU_SMS_OS if the use is to provide an OS-healthy heartbeat, or SAHPI_WTU_OEM if it is used for some other purpose.

This columnar node represents the subset of events that are Software Events.

Event table.

Software events.

Refer to the textual convention for more details.

The following type defines the types of events that can be reported by the HPI software implementation. Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'audit': 1, 'other': 3, 'startup': 2, 'undefined': 0.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This columnar node represents the subset of events that are OEM Events.

Event table.

OEM events.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This columnar node represents the subset of events that are User Events.

Event table.

User events.

Refer to SaHpiTextType for more details.

Refer to hpiTextLanguage for more details.

Refer to hpiText for more details.

This columnar node contains the status of the row and also perform add and delete operations. The status column uses four defined values: - `active(1)', which indicates that the conceptual row is available for use by the managed device; - `createAndGo(4)', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device). This function is used to add a User Alarm to this User Event Table and also to the to the Domain Alarm Table; When creating this row, the value of hpiEventSeverity indice must not be one of these minor(3), major(2), and critical(3). The effect of creating a new row will also be reflected in the DAT - with a new row there. - `destroy(6)', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. This function allows the HPI MIB User to delete a single User Alarm from the User Event Table and Domain Alarm Table. Only User Alarms added to the DAT and User Event Table can be deleted. To delete a single, specific alarm, set the hpiDomainAlarmId parameter to a value representing an actual User Alarm in the User Event Table.

The number of announcements present on this system.

Table of Announcements.

The table of announcements is used to provide a common interface to varied mechanisms for announcing conditions. Each announcement in an Annunciator's current set contains a severity level, details describing the specific condition that is being reported, an Acknowledged flag, a timestamp indicating when the announcement was added to the set, and an EntryId that uniquely identifies the particular status item within the set. EntryIds are assigned to announcements as they are added to the set as well as a Timestamp. After an announcement is deleted from the current set, its EntryId may be reused for a newly added announcement as long as the new announcement will have a different timestamp than any previously deleted announcement using the same EntryId. Thus, the EntryId and Timestamp together will uniquely identify any announcement, which was ever present in the Annunciator's set. The actual meaning of the Acknowledged flag is arbitrary, and the actions taken by the platform when announcements are flagged as 'acknowledged' or 'unacknowledged' are implementation-specific. The intended use of the flag is to indicate whether a particular announcement in the current set has been recognized by whomever or whatever is inspecting the LEDs, displays, etc., that are being driven by the Annunciator management instrument. Thus, when announcements are added to the current set, generally the flag should be set to indicate that the condition is 'unacknowledged'. Later, either as the result of an HPI User function call, or due to some implementation-dependent action (such as pressing an 'acknowledge' button on a front-panel display), the flag can be changed to indicate that the announcement is now 'acknowledged.' The ability to acknowledge announcements is not controlled by the Annunciator 'mode' setting (Auto, User, or Shared). Any announcement may be acknowledged by the HPI implementation, or via the hpiAnnunciatorAcknowledge() function call, regardless of the current mode setting for the Annunciator. Over time, announcements are added to and deleted from an Annunciator`s current set of announcements. This may be done automatically by the HPI implementation to reflect platform fault conditions, or by the HPI User via the HPI interface. When announcements are added or deleted automatically by the HPI implementation, it is implementation-specific which announcements are added or removed.

Entry ID for record Table Related Type Definitions SAHPI_FIRST_ENTRY 0x00000000 SAHPI_LAST_ENTRY 0xFFFFFFFF

Time when announcement added to set.

True if added to set by HPI User, False if added automatically by HPI implementation.

Only used with DAT and Annunciator functions. This is not a valid severity for events or alarms. Enumeration: 'major': 2, 'ok': 5, 'undefined': 0, 'allSeverities': 256, 'critical': 1, 'debug': 241, 'informational': 4, 'minor': 3.

Acknowledged flag.

Status Condition Type. Enumeration: 'resource': 2, 'sensor': 1, 'undefined': 0, 'oem': 3, 'user': 4.

Entity assoc. with status condition. This object converts HPI's hpiEntityPathT structure and an OpenHPI canonical string. The canonical string is formed by removing the SAHPI_ENT_ prefix from the HPI types, and creating tuples for the entity types. Order of significance is inverted to make entity paths look more like Unix directory structure. It is also assumed that {ROOT,0} exists implicitly before all of these entries. For example: {SYSTEM_CHASSIS,2}{PROCESSOR_BOARD,0}

Sensor associated with status Only valid if Type is SAHPI_STATUS_COND_TYPE_SENSOR.

Sensor event state. Only valid if Type is SAHPI_STATUS_COND_TYPE_SENSOR..

AIS compatible identifier associated with Status condition.

Manufacturer Id associated with status condition, required when type is SAHPI_STATUS_COND_TYPE_OEM.

Field Data. See Definition for SaHpiTextType for more details.

Field Data. See Definition for SaHpiTextLanguage for more details.

Field Data. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

This function allows the HPI User to delete a single announcement. Announcements may be deleted individually by specifying a specific index and setting this columnar node to destroy(6).

A table definining Event Log Information records.

Each resource has a Event Log Information record, which contains per resource pertient logging information. --FSC-DR Use hpiResourceId = 0 (SAHPI_UNSPECIFIED_RESOURCE_ID) to address the Domain Event Log.

The number of active entries contained in the log.

The total number of entries the log is able to hold.

The UserEventMaxSize entry indicates the maximum size of the text buffer data field in an HPI User event that is supported by the Event Log implementation. If the implementation does not enforce a more restrictive data length, it should be set to SAHPI_MAX_TEXT_BUFFER_LENGTH (255).

The UpdateTimestamp entry denotes the time of the last update to the Event Log. Refer to SaHpiTime for full description.

The Time entry denotes the Event Log's idea of the current time; i.e the timestamp that would be placed on an entry if it was added now. Remarks: Entries placed in the Event Log after this function is called will have Event Log timestamps (i.e., the Timestamp field in the SaHpiEventLogEntryT structure) based on the new time. Setting the clock does not affect existing Event Log entries. If the time is set to a relative time, subsequent entries placed in the Event Log will have an Event Log timestamp expressed as a relative time; if the time is set to an absolute time, subsequent entries will have an Event Log timestamp expressed as an absolute time. This function only sets the Event Log time clock and does not have any direct bearing on the timestamps placed on events (i.e., the Timestamp field in the SaHpiEventT structure), or the timestamps placed in the domain RPT info record. Setting the clocks used to generate timestamps other than Event Log timestamps is implementation-dependent, and should be documented by the HPI implementation provider. Some underlying implementations may not be able to handle the same relative and absolute time ranges, as those defined in HPI. Such limitations will be documented in implementation-specific documentation. When a time value is set in a region that is not supported by the implementation, an error code of SNMP_GENERROR will be returned. Refer to SaHpiTime for full description.

The Enabled entry indicates whether the log is enabled. If the event log is 'disabled' no events generated within the HPI implementation will be added to the event log. User events may still be added to the event log. When the event log is 'enabled' events may be automatically added to the event log as they are generated in a resource or a domain, however, it is implementation-specific which events are automatically added to any event log.

The OverflowFlag entry indicates the log has overflowed. Events have been dropped or overwritten due to a table overflow.

Indicates if the the overflow falg can be cleared by calling hpiEventLogInfoOverflowReset.

The OverflowAction entry indicates the behavior of the event log when an overflow occurs. drop(1) New entries are dropped when log is full overwrite(2) Event Log overwrites existing entries when Event Log is full Enumeration: 'drop': 1, 'undefined': 0, 'overwrite': 2.

This function erases the contents of the specified Event Log. Enumeration: 'clearLog': 1, 'undefined': 0.

A table definining Event Log records.

A table definining Event Log records.

This section defines the types associated with the SEL.

Severity of event. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'major': 2, 'ok': 5, 'undefined': 0, 'critical': 1, 'debug': 241, 'informational': 4, 'minor': 3.

Refer to SaHpiTime for full description.

Enumeration: 'unspecified': -1.

Refer to SaHpiTime for full description.

The type of event. Note: The enumerated named have +1 added as opposed to the SA HPI spec for the same constants. Enumeration: 'domain': 2, 'resource': 1, 'undefined': 0, 'hpiSoftware': 7, 'user': 9, 'oem': 8, 'watchdog': 6, 'hotswap': 5, 'sensor': 3, 'sensorEnableChange': 4.

This columnar node represents the subset of events that are Resource Events.

Event table.

Resource events.

Resource events are sent to indicate the failure or subsequent restoration of a resource. Resource events can also be used to announce the addition of a non-FRU resource to the RPT table. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'resourceRestored': 2, 'resourceAdded': 3, 'undefined': 0, 'resourceFailure': 1.

hpiDomainEventEntryCount represents the subset of events that are Domain events.

Event table.

Domain events.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT. Enumeration: 'domainRefRemoved': 2, 'undefined': 0, 'domainRefAdded': 1.

Domain Id of domain added to or removed from DRT.

This columnar node represents the subset of events that are Sensor Events.

Event table.

Sensor events.

Refer to the textual convention for more details.

Event category: See TEXTUAL-CONVENTION, SaHpiEventCategory.

Sensor Events and Sensor Event States: Each Event State may be asserted or deasserted. The set of Event States a sensor may support is defined by the sensor's 'Event Category.' A particular sensor, however, does not have to support all the Event States defined for its event category. The specific Event States that a particular sensor supports are indicated in the 'Events' field in the sensor's RDR. A sensor is not required to support any Event States. If no Event States are supported by a sensor, the 'Events' field will be 0x0000. A sensor may not support any Event States that are not defined for its event category. Each Event State is independent, although in some event categories the meaning assigned to the Event States will imply that certain Event States will be mutually exclusive. For example, a sensor that uses the SAHPI_EC_LIMIT event category should only have one of the two Event States, SAHPI_ES_LIMIT_NOT_EXCEEDED or SAHPI_ES_LIMIT_EXCEEDED asserted at any one time. Except where mutual exclusion is implied, however, sensors may have multiple Event States asserted simultaneously. For example, the event category SAHPI_EC_THRESHOLD uses six different event states to report the relationship between the value currently measured by the sensor and up to six different 'threshold' values. Each threshold is independently examined, and each Event State that represents a threshold that has been 'crossed' will be asserted. Threshold values must be configured so that 'Minor', 'Major' and 'Critical' thresholds are increasingly extreme readings, such that when a 'Major' threshold has been crossed, the corresponding 'Minor' threshold will also have been crossed, and thus both Event States will be asserted. When a sensor Event State is asserted or deasserted, an event may be generated by the resource. The generated event identifies the sensor and the event state being asserted or deasserted. The HPI implementation may assign event severity levels for each event state assertion or deassertion on an individual sensor basis.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to SaHpiEventState textual convention for more details.

Reserved for OEM use.

This columnar node represents the subset of events that are Sensor Enable ChangeEvents.

Event table.

Sensor Enable Change events.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Current sensor enable status.

Current event enable status.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Current set of asserted Event states.

This columnar node represents the subset of events that are HotSwap Events.

Event table.

Hot Swap events.

Refer to the textual convention for full details.

Refer to the textual convention for full details.

This columnar node represents the subset of events that are Watchdog Events.

Event table.

Watchdog events.

These enumerations represent the possible actions to be taken upon watchdog timer timeout and the events that are generated for watchdog actions. Enumeration: 'reset': 2, 'powerCycle': 4, 'powerDown': 3, 'noAction': 1, 'timerInt': 9, 'undefined': 0.

These enumerations represent the possible types of interrupts that may be triggered by a watchdog pre-timer event. The actual meaning of these operations may differ depending on the hardware architecture.

Watchdog Timer Use These enumerations represent the possible watchdog users that may have caused the watchdog to expire. For instance, if watchdog is being used during power on self test (POST), and it expires, the SAHPI_WTU_BIOS_POST expiration type will be set. Most specific uses for Watchdog timer by users of HPI should indicate SAHPI_WTU_SMS_OS if the use is to provide an OS-healthy heartbeat, or SAHPI_WTU_OEM if it is used for some other purpose.

This columnar node represents the subset of events that are Software Events.

Event table.

Software events.

Refer to the textual convention for more details.

The following type defines the types of events that can be reported by the HPI software implementation. Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'audit': 1, 'other': 3, 'startup': 2, 'undefined': 0.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This columnar node represents the subset of events that are OEM Events.

Event table.

OEM events.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This columnar node represents the subset of events that are User Events.

Event table.

User events.

Refer to SaHpiTextType for more details.

Refer to hpiTextLanguage for more details.

Refer to hpiText for more details.

This columnar node contains the status of the row and also perform add and delete operations. The status column uses four defined values: - `active(1)', which indicates that the conceptual row is available for use by the managed device; - `createAndGo(4)', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device). This function is used to add a User Alarm to this User Event Table and also to the to the Domain Alarm Table; When creating this row, the value of hpiEventSeverity indice must not be one of these minor(3), major(2), and critical(3). The effect of creating a new row will also be reflected in the DAT - with a new row there. - `destroy(6)', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. This function allows the HPI MIB User to delete a single User Alarm from the User EventLog Table and Domain Alarm Table. Only User Alarms added to the DAT and User EventLog Table can be deleted. To delete a single, specific alarm, set the hpiDomainAlarmId parameter to a value representing an actual User Alarm in the User EventLog Table.

Number of resource data records in this system.

A table definining RDR records.

The following describes the different types of records that exist within a RDR repository and the RDR super-structure to all of the specific RDR types (sensor, inventory data, watchdog, etc.).

Type of RDR entry. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'undefined': 0, 'ctrlRdr': 2, 'sensorRdr': 3, 'watchdogRdr': 5, 'annunciatorRdr': 6, 'inventoryRdr': 4, 'noRecord': 1.

Resource Data Record identifier - the instrumentID. Together with the hpiRdrType this identifies the RDR within a resource. Note: this is not the RDR record ID

If resource manages a FRU, entity path of the FRU. If resource manages a single entity, entity path of that entity. If resource manages multiple entities, the entity path of the 'primary' entity managed by the resource. Must be set to the same value in every domain which contains this resource. This object converts HPI's hpiEntityPathT structure and an OpenHPI canonical string. The canonical string is formed by removing the SAHPI_ENT_ prefix from the HPI types, and creating tuples for the entity types. Order of significance is inverted to make entity paths look more like Unix directory structure. It is also assumed that {ROOT,0} exists implicitly before all of these entries. For example: {SYSTEM_CHASSIS,2}{PROCESSOR_BOARD,0}

Entity is a FRU. This field is Only valid if the Entity path given in the 'Entity' field is different from the Entity path in the RPT entry for the resource.

See definition

See definition

ID String of the RDR entry.

ID String of the RDR entry in readable form. (valid only, if type == (text, , ) and language == ?).

Number of control data records in this system.

The number of control resource data records in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

This enumeration defines the what the control's output will be. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'led': 2, 'undefined': 0, 'generic': 1, 'audible': 6, 'powerInterlock': 8, 'dryContactClosure': 4, 'frontPanelLockout': 7, 'oem': 11, 'fanSpeed': 3, 'powerState': 9, 'lcdDisplay': 10, 'powerSupplyInhibit': 5.

This enumerated type defines the different types of generic controls. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'undefined': 0, 'stream': 4, 'text': 5, 'discrete': 2, 'oem': 193, 'digital': 1, 'analog': 3.

This object describes how the control is managed. The control may be managed automatically by the implementation (auto mode). Or it may be managed by the HPI User (manual mode). Some controls allow their modes to be changed, allowing the HPI User to determine if they will manage the control, or relinquish the management to the implementation. But, other controls do not allow the mode to be changed. These static-mode controls are indicated with the hpiCtrlReadOnly flag set as part of the default control mode. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'auto': 1, 'manual': 2, 'undefined': 0.

Indicates if mode is read-only

Indicates if mode is write-only

Reserved for OEM use

The number of control resource data records of type DIGITAL in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

Enumeration: 'on': 2, 'pulseOff': 3, 'pulseOn': 4, 'off': 1, 'undefined': 0.

Enumeration: 'on': 2, 'pulseOff': 3, 'pulseOn': 4, 'off': 1, 'undefined': 0.

The number of control resource data records of type DISCRETE in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

The number of control resource data records of type ANALOG in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

The number of control resource data records of type STREAM in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

The number of control resource data records of type OEM in the system.

A table definining Control Resource Data Records.

Definition of the control resource data record.

Number of sensor data records in this system.

The number of sensor resource data records in the system.

A table definining Sensors records.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

True if HPI User can enable or disable sensor via hpiSensorEnableSet.

When reading, this object returns the current sensor enable status for an addressed sensor. When writing this object sets the sensor enable status for an addressed sensor. If a sensor is disabled, the rows in hpiSensorReadingCurrent for that sensor will not be present, and no events will be generated for the sensor.

The Bit mask Events is not SAHPI_ES_UNSPECIFIED

The current event state of a sensor

Sensors category. Sensor events contain an event category and event state. Depending on the event category, the event states take on different meanings for events generated by specific sensors. The generic(128) category can be used for discrete sensors which have state meanings other than those identified with other event categories.

perEvent(1) Event message control per event, or by entire sensor; sensor event enable Status can be changed, and assert/deassert masks can be changed. readOnlyMasks(2): Control for entire sensor only; sensor event enable status can be changed, but assert/deassert masks cannot be changed. readOnly(3): Event control not supported; sensor event enable status cannot be changed and ssert/deassert masks cannot be changed. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'readOnlyMasks': 2, 'readOnly': 3, 'undefined': 0, 'perEvent': 1.

When reading, this object returns the current sensor event enable status for an addressed sensor. When writing this object sets the sensor event enable status for an addressed sensor. If event generation for a sensor is disabled, no events will be generated as a result of the assertion or deassertion of any event state, regardless of the setting of the assert or deassert event masks for the sensor. If event generation for a sensor is enabled, events will be generated when event states are asserted or deasserted, according to the settings of the assert and deassert event masks for the sensor. Event states may still be read for a sensor even if event generation is disabled, by reading the hpiSensorReadingCurrent table.

Indicates if sensor data readings are supported.

Defines which range flags the sensor supports. They can be MIN, MAX, NOMINAL, NORMAL_MAX, NORMAL_MIN, or nothing if the sensor does not support any ranges.

Reserved for OEM use.

The number of sensor resource data records in the system.

A table definining Sensors records.

This is the sensor resource data record which describes all of the static data associated with a sensor.

The Accuracy Factor is expressed as a floating point percentage (e.g. 0.05 = 5%) and represents statistically how close the measured reading is to the actual value. It is an interpreted value that figures in all sensor accuracies, resolutions, and tolerances.

The number of sensor resource data records in the system.

A table definining Sensors records.

This is the sensor resource data record which describes all of the static data associated with a sensor.

The number of sensor resource data records in the system.

A table definining Sensors records.

This is the sensor resource data record which describes all of the static data associated with a sensor.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

This is the sensor resource data record which describes all of the static data associated with a sensor.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Refer to the textual convention for more details.

Number of inventory data records in this system.

The number of inventory resource data records present on this system.

Table defining entity inventory resource data records.

These structures are used to read and write inventory data to entity inventory repositories within a resource. All inventory data contained in an inventory data repository (IDR) must be represented in the RDR repository

True indicates that updates to IDR are automatically and immediately persisted. False indicates that updates are notimmediately persisted; but optionally may be persisted via hpiParmControl function, as defined in implementation documentation.

OEM value for the Idr record. This is manufacturere' specific value.

The count is incremented any time the IDR is changed.

Describes if the IDR is read-only. If such, all area headers and fields are flagged as well.

Number of area containted in IDR

The number of inventory resource area data records present on this system.

Table defining inventory data respoitory data area records.

These structures are used to read and write inventory data respository data area records. The four-tuple index value consits of: - hpiDomainId, which is the domain of the resource - hpiResourceId, the id value for the resource - hpiIdrId, the id value of entity inventory - hpiAreaId, the id value of inventory data area. New Area's are Created when 'hpiIdrAreaType' is written with the appropriate index values's. The 'AreadId' index is ignored. SAI-HPI-B.01.01, pages 98...100, 104.

See TEXTUAL-CONVENTION 'SaHpiInstrumentId'

The type of Area. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'undefined': 0, 'unspecified': 256, 'productInfo': 180, 'internalUse': 177, 'oem': 193, 'chassisInfo': 178, 'boardInfo': 179.

Describes if an area is read-only. All area headers in a read-only IDR are flagged as read-only as well.

Number of Fields contained in Area

This columnar node contains the status of the row and also perform add and delete operations. The status column uses three defined values: - `active(1)', which indicates that the conceptual row is available for use by the managed device; - `notInService(2)', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device. - `createAndWait(5)', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device). This function is used to add an Area to the specified Inventory Data Repository. The row is created (and changes state to 'active' when the hpiAreaType has been correctly set) to a new instance of the conceptual row. The dis-allowed hpiAreaType value is undefined(0) and unspecified(256) - `destroy(6)', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. This function allows the HPI MIB User to delete an Inventory Data Area, including the Area header and all fields contained with the area, from a particular Inventory Data Repository. In some implementations, certain Areas are intrinsically read-only. The hpiAreaIsReadOnly flag, indicates if the Area is read-only. If the Inventory Data Area is not read-only, but contains a Field that is read-only, the Area cannot be deleted. An attempt to delete an Area that contains a read-only Field will return an error.

The number of inventory data repository IdrField records.

Table defining inventory data repository IdrField records.

These structures are used to read and write inventory data repository IdrField records.

See TEXTUAL-CONVENTION 'SaHpiInstrumentId'

Inventory Data IdrField type definitions. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'mfgDatetime': 2, 'custom': 10, 'undefined': 0, 'assetTag': 9, 'serialNumber': 6, 'unspecified': 256, 'productName': 4, 'productVersion': 5, 'chassisType': 1, 'partNumber': 7, 'fileId': 8, 'manufacturer': 3.

Describes if an IdrField is read-only. All IdrField headers in a read-only IDR are flagged as read-only as well.

IdrField Data. See Definition for SaHpiTextType for more details.

IdrField Data. See Definition for SaHpiTextLanguage for more details.

IdrField Data. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

IdrField Data. The type of date is specified by hpiResourceTagTextType and hpiResourceTagLanguage.

This object provides a method to create and delete a Data Inventory IdrField. Supported states are: active(1), notInService(2), createAndWait(5), destroy(6) The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has four defined values: - `active(1)', which indicates that the conceptual row is available for use by the managed device. For it to in such state, the columnar objects: hpiIdrFieldType, hpiIdrFieldTextType, hpiTextLanguage, and hpiIdrFieldText must have valid values. - `notInService(2)', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device. - `createAndWait(5)', which is supplied by a management station wishing to create a new instance of a conceptual row. After setting this value, the management station is responsible of providing valid values to the columnar objects: hpiIdrFieldIsReadOnly, hpiIdrFieldType, hpiIdrFieldTextType, hpiTextLanguage and hpiIdrFieldText. - `destroy(6)', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.

Number of watchdogs data records in this system.

The number of watchdogs present on this system.

Table of watchdog resource data records.

When the 'Watchdog' capability is set in a resource, a watchdog with an identifier of SAHPI_DEFAULT_WATCHDOG_NUM is required. All watchdogs must be represented in the RDR repository with an hpiWatchdogRecT, including the watchdog with an identifier of SAHPI_DEFAULT_WATCHDOG_NUM.

If you read this object, it means: Log - indicates whether or not the Watchdog is configured to issue an event when it next times out. TRUE=event will be issued on timeout. If you set this object, it means: Log - indicates whether or not the Watchdog should issue an event when it next times out. TRUE=event will be issued on timeout. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

If you read this object, it means: Running - indicates whether or not the Watchdog is currently running or stopped. TRUE=Watchdog is running. If you set this object, it means: Running - indicates whether or not the Watchdog should be stopped before updating. TRUE = Watchdog is not stopped. If it is already stopped, it will remain stopped, but if it is running, it will continue to run, with the countdown timer reset to the new InitialCount. Note that there is a race condition possible with this setting, so it should be used with care. FALSE = Watchdog is stopped. After this object is set, a subsequent read on this object is required to start the timer.

If you read this object, it means: TimerUse - indicates the current use of the timer; one of five preset uses which was included on the last SET object request, or through some other implementation-dependent means to start the Watchdog timer. If you set this object, it means: TimerUse - indicates the current use of the timer. Will control which hpiWatchdogTimerUseExpFlags is set if the timer expires Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

Indicates what action will be taken when the Watchdog times out. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1). Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'reset': 2, 'powerDown': 3, 'powerCycle': 4, 'undefined': 0, 'noAction': 1.

PretimerInterrupt - indicates which action will be taken 'PreTimeoutInterval' seconds prior to Watchdog timer expiration. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

PreTimeoutInterval indicates how many milliseconds prior to timer time out the PretimerInterrupt action will be taken. If 'PreTimeoutInterval' = 0, the PretimerInterrupt action will occur concurrently with 'TimerAction.' HPI implementations may not be able to support millisecond resolution and may have a maximum value restriction. These restrictions should be documented by the provider of the HPI interface. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

Set of values seperated by a delimiter. For each value set, the corresponding Timer Use Expiration Flag will be CLEARED. Generally, a program should only clear the Timer Use Expiration Flag corresponding to its own TimerUse, so that other software, which may have used the timer for another purpose in the past can still read its TimerUseExpFlag to determine whether or not the timer expired during that use. The values are: EXP_BIOS_FRB2 EXP_BIOS_POST EXP_OS_LOAD EXP_SMS_OS EXP_OEM Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

InitialCount - The time, in milliseconds, before the timer will time out after a SaHpiWatchdogTimerReset() function call is made, or some other implementation-dependent strobe is sent to the Watchdog. HPI implementations may not be able to support millisecond resolution and may have a maximum value restriction. These restrictions should be documented by the provider of the HPI interface. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

PresentCount - The remaining time in milliseconds before the timer will time out unless a SaHpiWatchdogTimerReset() function call is made, or some other implementation- dependent strobe is sent to the Watchdog. HPI implementations may not be able to support millisecond resolution on watchdog timers, but will return the number of clock ticks remaining times the number of milliseconds between each tick. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

This object provides a method to start or restart the watchdog timer from the initial countdown value. Setting this to true(1) will 'strobe' the counter and reset to the initial countdown value as specified in hpiWatchdogTimerInitialCount. Setting this object will NOT take effect on the Watchdog until the object SaHpiWatchdogRunning is set to true(1).

Reserved for OEM use

Number of annunciators data records in this system.

The number of annunciators present on this system.

Table of Annunciator resource data records.

The Annunciator table is used to control the set of annunciators associated with a resource. An Annunciator management instrument holds a set of individual announcements. The function of the Annunciator is to communicate the contents of its current set via whatever platform-specific mechanism is associated with that particular Annunciator management instrument. For example, if announcements are to be communicated via lighting a set of LEDs on a front-panel display, the Annunciator management instrument may analyze its current set of announcements and turn on a single LED reflecting the most severe condition found, or turn on a 'System Ok' LED if there are currently no items in the set. A different Annunciator may continuously scroll each announcement in its set on a text display, as well as turning on LEDs and setting dry-contact relays to reflect the severity of conditions present. A third Annunciator may announce items in its set by sending messages to a proprietary management system, or by sending emails or pages to a system technician. The Annunciator provides a common interface to these varied mechanisms for announcing conditions, so the HPI User is not burdened by platform-to-platform differences. However, the current content of any annunciator management instrument is not defined by the HPI standard in the same way that the contents of the DAT are defined. Thus, the HPI implementation and HPI Users can exert more control over what conditions should be announced. Further, a platform can contain multiple Annunciator management instruments, each reflecting a different physical announcement device in the platform. By exposing each separately, HPI Users and the HPI implementation can control which conditions are handled by each announcement device. An Annunciator management instrument may be implemented using other HPI controls that are in 'auto' mode; for example, digital controls to turn LEDs on and off, stream controls to sound audible alerts, and/or text controls to display detailed information. However, A nnunciators may also operate directly to report conditions using mechanisms that are not themselves visible directly in the HPI interface. Over time, announcements are added to and deleted from an Annunciator`s current set of announcements. This may be done automatically by the HPI implementation to reflect platform fault conditions, or by the HPI User via the HPI interface. When announcements are added or deleted automatically by the HPI implementation, it is implementation-specific which announcements are added or removed.

Unique Number identifying each annunciator.

The following enumerated type defines the possible output types which can be associated with an Annunciator Management Instrument. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'led': 1, 'undefined': 0, 'composite': 6, 'dryContactClosure': 2, 'oem': 7, 'message': 5, 'lcdDisplay': 4, 'audible': 3.

if True, Mode may not be changed by HPI User.

maximum number of conditions that can be held in current set. 0 means no fixed limit.

The Annunciator management instrument has a current mode that indicates whether announcements are added and removed automatically by the HPI implementation, by the HPI User, or both. The mode may be set to one of three values, with the following meanings: auto(1) - the HPI implementation automatically adds and deletes announcements; the HPI User is not permitted to add or delete announcements. user(2) - the HPI User may add and delete announcements; the HPI implementation will not automatically add or delete announcements. shared(3) - the HPI implementation automatically adds and deletes announcements and the HPI User may also add and delete announcements. The initial mode of each Annunciator is implementation-specific. The HPI User may change the mode of Annunciators with the hpiAnnunciatorMode object. However, the mode may be configured to be Read-only, in which case the HPI User will not be able to change the mode. When the mode is user(2) or shared(3), HPI Users may add or delete any types of announcements in the Annunciator's current set - not just HPI User announcements. This is allowed so that the HPI User can exert complete control over what conditions are being announced, if that is required. Note that this is less restrictive than the similar operations on the DAT. To distinguish between announcements added to an Annunciator automatically and those added by an HPI User, an hpiAddedByUser IdrField in the announcement indicates the source of the announcement in the set. Note: Enumerated values are increased by one value compared to SAI-HPI-B spec. Enumeration: 'shared': 3, 'auto': 1, 'undefined': 0, 'user': 2.

maximum number of conditions that can be held in current set. 0 means no fixed limit. if True, Mode may not be changed by HPI User.

Forward pointer to the RDR OID.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Resource (RPT) change event notifications.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Domain events are used to announce the addition of domain references and the removal of domain references to the DRT.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Sensor event notification.

Hot swap notification.

Hot swap notification.

Hot swap notification.

Hot swap notification.

Hot swap notification.

Hot swap notification.

Hot swap notification.

Watchdog notification.

Watchdog notification.

Watchdog notification.

Watchdog notification.

Watchdog notification.

Watchdog notification.

Watchdog notification.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

Audit events report a discrepancy in the audit process. Audits are typically performed by HA software to detect problems. Audits may look for such things as corrupted data stores, inconsistent RPT information, or improperly managed queues. Startup events report a failure to start-up properly, or inconsistencies in persisted data.

OEM event notifications.

OEM event notifications.

OEM event notifications.

OEM event notifications.

OEM event notifications.

OEM event notifications.

OEM event notifications.

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().

User events may be used for storing custom events created by an HPI User when injecting events into the Event Log using hpiEventLogEntryAdd().