SPI Programming Manual (G06.24+, H06.03+, J06.03+)

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-47
Control of Types of Response Records
do define standard error lists (for instance, some system procedures such as
NEWPROCESS), and if your subsystem encounters critical errors in calls to the SPI
procedures, HP recommends that you return error lists to applications in the standard
form, and use the appropriate HP definition files for the tokens in these error lists rather
than defining your own.
SPI servers should report these error conditions:
•
Empty response
•
Command too long
•
Bad context
•
Response longer than expected
•
Wrong subsystem ID in command
•
Command requires newer version of server
•
Extraneous token in a command
•
Error from another subsystem or from SPI (if desired, your subsystem can define
different error numbers for different sources of the error)
•
Required token is missing (you can define either a single error number for all cases
or many individual error numbers for the different tokens)
•
Command parameter has an invalid value (you can define either a single error
number for all cases or many individual error numbers for the different parameters)
Control of Types of Response Records
To let requesters ask for either all response records or only those with errors or
warnings, include support for the ZSPI-TKN-RESPONSE-TYPE token, as some
NonStop Kernel subsystems do.
Continuing Despite Errors
To let requesters specify under what conditions your server should continue
processing on a set of objects, you can support the ZSPI-TKN-ALLOW-TYPE token as
some NonStop Kernel subsystems do. For guidelines governing the use of this token,
see ZSPI-TKN-ALLOW-TYPE
on page 4-31.
Reporting Errors From the SPI Procedures
These recommendations for all NonStop Kernel subsystems describe how a server
should report errors from the SPI procedures.