TS/MP Management Programming Manual (G06.24+, H06.03+)
Event Management
NonStop TS/MP Management Programming Manual—540082-001
10-16
Retrieving and Decoding Event Messages
Retrieving and Decoding Event Messages
When using the management programming interface to manage your Pathway
subsystem, you can specify a subtype 30 process as an EMS collector. An EMS
collector is a type of logging device (as is a log file). Subtype 30 processes, which are
supported by the PATHMON process, are nonprivileged processes that simulate
terminals and communication devices. If you specify an EMS collector as a logging
device, specify EVENTFORMAT for the logparam parameter so that the messages
are logged in event message format and not as PATHCOM text messages.
Here is a summary of the steps your application must take to retrieve and act upon
event messages:
1. Declare a buffer of appropriate size for the Event Management Service (EMS)
GETEVENT command and its response. (For recommended sizes, see Event-
Management Considerations on page 10-17.)
2. Start an EMS consumer distributor and open it with the #ZSPI qualifier.
3. Format an EMS distributor CONTROL programmatic command to load a filter you
have written and to specify the source and destination of event messages, if
desired. Send the CONTROL command to the consumer distributor by using the
mechanism appropriate to your programming language (for example, a
WRITEREAD call in TAL).
4. Read the response from the distributor by using the mechanism appropriate to
your programming language (for example, a WRITEREAD call in TAL).
5. Repeat these steps for each event message:
a. Format and send a GETEVENT command to the consumer distributor to get
the next event message, using the mechanism appropriate to your
programming language (for example, a WRITEREAD call in TAL).
b. Read the response from the distributor by using the mechanism appropriate to
your programming language (for example, a WRITEREAD call in TAL).
c. Call SSMOVE or SSMOVETKN to move the context token from the response
buffer into the GETEVENT command buffer. The context token is needed
when your application resends the command to get the next event.
d. Call SSGET or SSGETTKN to retrieve the token containing the event message
(ZEMS-TKN-EVENT) from the response buffer.
e. Call EMSGET or EMSGETTKN to retrieve the subsystem ID (ZSPI-TKN-SSID)
and the event number (ZEMS-TKN-EVENTNUMBER) from the event
message. Together, these two tokens identify the event message and
determine what information tokens it will contain.