TS/MP 2.5 Management Programming Manual

3 SPI Programming Considerations
After your subsystem and EMS processes are running and your management application has
established communication with the Pathway subsystem, the main business of your management
application is to format and send commands, decode responses and act on the results, and interpret
event messages and act on their information.
This section provides information about SPI programming and discusses SPI programming
considerations specific to the Pathway subsystem. Topics include:
• Definition files
• Message elements for the Pathway subsystem
• Using SPI to build and send commands
• Receiving and decoding response messages
• Error handling
• Security
• Naming guidelines for applications
• Programming considerations for specific object types
• Writing C programs
• Command presentation
For a complete list of all token codes and token maps specific to the Pathway subsystem, see the
ZPWYDDL file.
Definition Files
The commands, responses, and event messages sent to and received from the Pathway subsystem
are made up of items called tokens. Each token contains a particular piece of information, such
as a command parameter or an item of information about an event. Tokens can be single values
or structures consisting of several values. Some tokens, called header tokens, are present in every
command and response and in every event message.
Tokens and related data items for commands, responses, and event messages must be declared
in your management applications; these declarations are provided in the definition files. A set of
definition files is provided as part of each HP subsystem that supports DSM; a few other NonStop
software components (such as SPI and EMS) also provide definition files. Each software component
includes definition files for the TAL, COBOL, TACL, C, and DDL languages.
To use the data declarations defined by a particular NonStop software component, your application
must incorporate the appropriate programming-language definition file associated with that software
component. The declarations in a COBOL definition file are grouped into sections to enable COBOL
programs to declare multiple copies of structures in the definition file. TAL programs can use as a
source either the entire definition file or just the sections they require. The TACL command interpreter
always loads the entire definition file. For further information about how definition files are used
by an application, see the SPI Programming Manual.
Naming Conventions
Definition files are named according to these conventions:
ZSPIDEF.ZsubsysC
ZSPIDEF.ZsubsysCOB
ZSPIDEF.ZsubsysDDL
ZSPIDEF.ZsubsysPAS
Definition Files 29