TS/MP 2.5 Management Programming Manual

ZSPI-TKN-ERROR, indicating the Pathway subsystem ID and the value
ZPWY-ERR-PM-ALREADYSTARTED
ZPWY-TKN-REQCOMMAND, containing ZPWY-CMD-START
ZPWY-TKN-REQOBJECTTYPE, containing ZPWY-OBJ-SC
ZPWY-TKN-REQSCNAME, containing "CLASS-A"
ZPWY-TKN-ERRCOMMAND, containing ZPWY-CMD-START
ZPWY-TKN-ERROBJECTTYPE, containing ZPWY-OBJ-SC
ZPWY-TKN-ERRSCNAME, containing "CLASS-A"
ZSPI-TKN-ENDLIST
Scenario 2
Your management application issues the START SC command for CLASS-A, but the buffer is
corrupted. The response message contains:
The message header, including the command (ZPWY-CMD-START), the object type
(ZPWY-OBJ-SC), the version of the PATHMON process, and the subsystem ID
ZSPI-TKN-RETCODE, containing the value ZPWY-ERR-SPI-INVALIDBUFFER
ZSPI-TKN-ERRLIST
ZSPI-TKN-ERROR, indicating the Pathway subsystem ID and the value
ZPWY-ERR-SPI-INVALIDBUFFER
ZPWY-TKN-REQCOMMAND, containing the value ZSPI-TKN-NULL-COMMAND
ZPWY-TKN-REQOBJECTTYPE, containing the value ZSPI-TKN-NULL-OBJECT-TYPE
ZSPI-TKN-ENDLIST
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
(page 174).)
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).
Retrieving and Decoding Event Messages 173