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

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-50
Reporting Errors From the SPI Procedures
Some suggestions:
•
Your subsystem should stop immediately instead of attempting to continue.
•
If you do attempt to continue and report the failure, initialize and build a buffer for a
response (see Failure of SSGET on a Header Token
on page 5-48).
•
It is not imperative that you ignore ZSPI-TKN-MAXRESP. However, for simplicity, it
is recommended that you return a single response record per response.
•
If errors occur while attempting to build the response, your server can ignore them
and return whatever gets built as the response. This might result in a garbage
response, but in this situation it is unlikely that any other method would provide
more information.
It is assumed that when formatting a response in single-response-per-buffer form, your
subsystem initializes a buffer at least as large as the subsystem’s recommended size.
A “buffer full” error in that situation should be considered a serious error. If your
subsystem attempts to use the buffer length specified in the command message and
encounters a “buffer full” error, the corrective action is up to you to define.
The technique of building the response in the command buffer by using SSPUT with
ZSPI-TKN-DATAFLUSH to empty it is probably not a good idea. A problem in the
command buffer might cause a later SSPUT to fail, and certain garbage requests could
cause the server to stop. It is probably best to initialize a new buffer.
Failure of SSNULL
An error from SSNULL should be considered as serious as the errors from SSINIT or
SSPUT; it probably indicates the data stack has been corrupted, so it should cause the
server to stop.
If you do attempt to generate a response, proceed as in the case of SSINIT or SSPUT.
Error on SSMOVE
When using SSMOVE on a server-initialized buffer, you need to clear the last-error
information in at least the server-initialized buffer just before the operation (use SSPUT
with ZSPI-TKN-CLEARERR).
If an error occurs on SSMOVE, you can use SSGET with ZSPI-TKN-LASTERR on the
server-initialized buffer to determine whether the error was on the server-initialized
buffer. If it was, the error indicates data stack corruption of the server, and the server
should stop.
If you do attempt to generate a response, proceed as in the case of SSINIT or SSPUT.