OSI/AS Management Programming Manual

Retrieving and Decoding Event Messages
SPI Programming Considerations for OSI/AS
3–12 056785 Tandem Computers Incorporated
compatible mode, to the OPRLOG and any $AOPR process. The threshold event
messages, of concern only to applications that monitor thresholds, have ZEMS-TKN-
CONSOLE-PRINT set to ZSPI-VAL-FALSE and so are not sent to the console,
OPRLOG, or $AOPR. You can override the value of ZEMS-TKN-CONSOLE-PRINT
using the OVERRIDE option of the DSM template compiler, as described in the DSM
Template Services Manual.
OSI/AS does not report any action events (normal occurrences that require operator
intervention).
The maximum buffer size needed for any OSI/AS event message is 4024 bytes. The
minimum buffer size for the OSI/AS threshold events is 2500 bytes.
Some OSI/AS event messages contain extensible structured tokens providing
information for use by your application. In addition, some OSI/AS 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 Tandem
representative. The descriptions of individual event messages in Section 6 explain
what to do with each error list.
Critical Events Events reported by OSI/AS 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 event-message 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
noncritical.
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/AS, a filter would examine
the token that contains the subsystem ID of the issuing subsystem and then allow only
those messages containing the OSI/AS 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 messages to select which event
messages will be returned to your application. You can create filters that return only
critical event messages, all messages associated with a particular device, all messages
with a certain event number, and so forth.
For examples of filters you could use to select event messages related to the OSI/AS
subsystem, refer to Appendix C.