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

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-54
Summary of Server Role
error. Omitting the token from the error list seems like a reasonable approach in
that case, but if that is not suitable, include explicit directions for what to do.
•
If a set of procedures are closely related (such as the HP file-system procedures),
such procedures can share a subsystem ID. In these cases, you should use the
token ZSPI-TKN-PROC-ERR token to indicate which of the procedures is involved.
Define a token value to denote each procedure in the group.
•
Instead of defining separate tokens for each item of interest, you can choose to
group some or all of the items into one or more extensible structured tokens.
Summary of Server Role
An SPI server must:
•
Verify, upon receipt of an SPI message, that the message is a valid SPI message
and that the message fits in the message buffer. (See Checking the Command
Message for Validity on page 5-31.)
•
Reject any request in which ZSPI-TKN-MAX-FIELD-VERSION contains a version
greater than the server’s version.
•
Reject any request that contains an unrecognized or invalid subsystem ID,
command number, object type, token code, or token value.
•
Set ZSPI-TKN-SERVER-VERSION to its own (the server’s) version.
•
Continue to recognize and process old-version requests and tokens for as long as
possible.
•
Accept but otherwise ignore any number of comment tokens (ZSPI-TKN-
COMMENT).
•
Check continuation requests to verify that the requester is not bypassing security
or forging a context token.
•
Support opens from a backup requester.
•
If a request is not safely repeatable, save sync IDs, replies, and any other
necessary information.
•
Always use a token map to retrieve the contents of an extensible structured token.