TS/MP Management Programming Manual (G06.24+, H06.03+)

SPI Programming Considerations
NonStop TS/MP Management Programming Manual—540082-001
3-14
Data Lists and Error Lists
Previously in the ZSPIDDL file, ZSPI-DDL-CHAR8 is defined as eight ASCII
characters. ZSPI-DDL-FNAME is defined as a Guardian internal format file name,
including disk name, process name, and device name.
Throughout this manual, the type of a field is indicated wherever the field is described.
Definitions for Pathway subsystem private token and field types are in Section 5,
ZPWY-DDL- Definitions, Section 6, ZPWY-TKN- Definitions, and Section 7, ZPWY-
MAP- Definitions. The type names defined by SPI (using the prefix ZSPI- ) are fully
described in the SPI Programming Manual.
Data Lists and Error Lists
Responses from the Pathway subsystem can contain data lists and error lists as
described in the SPI Programming Manual.
The Pathway subsystem does not support arrays or multiple instances of tokens. The
PATHMON process never returns more than one response in a message. However,
the single response can be enclosed in a data list for consistency with other
subsystems if you include the ZSPI-TKN-MAXRESP token with a value not equal to
zero.
Building and Sending a Command Message
These subsections summarize the steps your application must take to create and send
SPI commands. These summaries are followed by subsystem-specific programming
considerations for the Pathway subsystem.
For more information on creating and sending SPI commands and responses, see the
SPI Programming Manual.
Summary of Steps
This is a summary of the steps your application must take to build and send a
command message to the Pathway subsystem:
1. Declare a buffer of appropriate size. The constant ZPWY-VAL-BUFLEN designates
the buffer length you should use for Pathway requests.
2. Call the SSINIT procedure to initialize the command buffer. SSINIT sets the values
of certain header tokens, including the command, the object type, and the target
subsystem ID.
3. Call SSNULL to initialize each extensible structured token to be used in the
command.
4. Call SSPUT or SSPUTTKN to place the appropriate tokens in the buffer.
5. If you are resending a command to retrieve the next response message in a series,
call SSMOVE or SSMOVETKN to move the context token from the previous
response buffer into the command buffer.