Safeguard Management Programming Manual (G06.29+, H06.08+, J06.03+)
Event Management
Safeguard Management Programming Manual—422086-028
8-3
Elements of Event Messages for Safeguard
Subsystems
-- Send the message on to the application.
ELSE
FAIL -- This message concerns some other object.
ELSE
FAIL -- This is not a critical event message.
ELSE
FAIL; -- This is not a SAFEGUARD event message
END; -- of critical^SAFEGUARD/SAFEGUARD^messages.
Elements of Event Messages for Safeguard
Subsystems
Safeguard event messages are made up of special codes called tokens. Each token
contains a single element of the message, and each element contains one piece of
information about the event. There are no extensible structured tokens or lists in
Safeguard event messages. Some tokens, called header tokens, are present in every
message.
This manual does not attempt to give a complete explanation of tokens. It provides
subsystem-specific information about the tokens that appear in Safeguard event
messages. For general information about tokens, see the SPI Programming Manual
and the Event Message Service (EMS) Manual. For information about tokens common
to all data communications subsystems, see the SPI Common Extensions Manual.
To read event messages issued by the Safeguard subsystem, use the Subsystem
Programmatic Interface (SPI) as described in the SPI Programming Manual.
In this section, event-message tokens and their values are shown in DDL. For an
explanation of DDL as it applies to SPI, refer to the SPI Programming Manual.
Common Syntax Elements
The token-oriented programmatic interfaces to Safeguard consist of these syntax
elements:
•
Event numbers
•
Subjects for event messages
•
Tokens for elements of event messages
•
Constructs involving multiple tokens
The following paragraphs describe each kind of element and how it is used. For more
information, see the SPI Common Extensions Manual.
Naming Rules and Guidelines for Applications
By convention, HP uses names beginning with the letter Z for the definitions and for
the component fields of structures in its definition files. To avoid conflicts with names