OSI/MHS Management Programming Manual

SPI Programming Considerations for OSI/MHS
OSI/MHS Management Programming Manual—424824-001
3-10
Event-Management Considerations for OSI/MHS
h. If you encounter the error-list token (ZSPI-TKN-ERRLIST), make another call
to EMSGET or EMSGETTKN to retrieve the tokens inside the error list.
i. Take action appropriate to the information in the event message.
The EMS Manual provides information on how to retrieve tokens from an event
message.
Event-Management Considerations for OSI/MHS
The overall goal of event reporting by OSI/MHS is to allow the system operator or a
management program to monitor and control the operation of the subsystem. Event
reporting also provides accounting information for billing applications. The OSI/MHS
subsystem reports events to EMS but not to the Compaq Maintenance and Diagnostic
Subsystem (TMDS).
All event messages except the accounting events have ZEMS-TKN-CONSOLE-PRINT
set to the value ZSPI-VAL-TRUE.
The maximum buffer size needed for any OSI/MHS event message is 4024 bytes.
Some OSI/MHS event messages contain extensible structured tokens providing
information for use by your application. In addition, some OSI/MHS event messages
contain error lists. Some of these error lists provide information for use by your
application; others contain information you should report to your Compaq
representative. The descriptions of individual event messages in Section 6, Event
Messages, explain what to do with each error list.
Critical Events
Events reported by OSI/MHS are divided into two classes: critical and noncritical.
Critical events can have serious consequences, such as the loss of a device or the
occurrence of certain errors. Noncritical events are less serious, such as a network-
management counter exceeding a threshold. The value of the token ZEMS-TKN-
EMPHASIS indicates whether an event is critical. If the value is ZSPI-VAL-TRUE, the
event is critical; if the value is ZSPI-VAL-FALSE, the event is not critical.
Filters
EMS provides you with the ability to create filters, which allow applications to select
particular event messages from among those reported. Filters select messages to be
returned to an application by examining the values of tokens in the messages. For
example, to select only event messages reported by OSI/MHS, a filter would examine
the token that contains the subsystem ID of the issuing subsystem and then allow only
those messages containing the OSI/MHS subsystem ID to pass.
You code a filter in the EMS filter language, compile the filter source file with the EMS
filter compiler, and load the resulting filter when you run the EMS consumer distributor.
You can replace filters online.
It is recommended that your application always use a filter when retrieving event
messages. Otherwise, the application will receive all the event messages sent to the
event log on the local system. You can use any of the tokens contained in event