Guardian Application Conversion Guide

Converting Distributed Systems Management (DSM) Applications
Converting Other Parts of an Application
096047 Tandem Computers Incorporated 8–29
Generating Event
Messages
This subsection describes how to convert a DSM application (or a user-written
subsystem) that uses EMS to generate and report event messages.
Calling the EMSINIT Procedure
When your unconverted application calls the C-series EMSINIT procedure to build the
event-message header, EMSINIT places the process-ID token, ZEMS-TKN-CRTPID, in
the event-message header. The D-series EMSINIT procedure substitutes the process-
descriptor token, ZEMS-TKN-PROC-DESC, for ZEMS-TKN-CRTPID. The D-series
EMSINIT also places the node (system) name and number of the subsystem reporting
the event in the ZEMS-TKN-NODENAME and ZEMS-TKN-NODENUMBER tokens.
A D-series event message is larger than a C-series event message, because the D-series
header is approximately 24 bytes larger than the C-series header. A D-series event
message also has a variable-length structure, because the process-descriptor token
ZEMS-TKN-PROC-DESC in the header is a variable-length string. If necessary,
modify the event-message buffer in your application to hold the larger variable-length
event message.
Specifying File Names
Your DSM application might define a file-name token as a 12-word internal-format file
name. For example, it might define a file-name token using token type
ZSPI-TYP-FNAME.
Define a file-name token as a variable-length string using a token type such as
ZSPI-TYP-STRING. You can use this token for any kind of file name: disk file name,
device file name, or D-series process file name.
Specifying Node (System) Names and Numbers
Your DSM application might include a node (system) name or number token in your
event message other than in the header tokens described above.
If possible, use a node-name token rather than a node-number token in your event
messages. If you define a node-name token, use a variable-length string token with a
token type such as ZSPI-TYP-STRING.
In most cases, an 8-bit token for a node number is sufficient. However, if you define a
new node-number token, use a 32-bit token with a token type such as ZSPI-TYP-INT2.
Put zeros in the first three bytes and the node number in the last byte of this new
token.
Specifying CPU and PIN Values
Your DSM application might include an 8-bit CPU or PIN token or a 16-bit token for
both the CPU and PIN values in an event message. For example, you might define a
CPU or PIN value using token type ZSPI-TYP-BYTE, or a combined CPU and PIN
value using token type ZSPI-TYP-INT, ZSPI-TYP-UINT, or ZSPI-TYP-BYTE-PAIR.
Define separate unsigned integer tokens for the CPU and PIN values using a token
type such as ZSPI-TYP-UINT.