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

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-13
Receiving the Response
Error 2: Request Not an SPI Buffer
The process rejected a message because the requester had it open for SPI
commands, but the command was not a valid SPI buffer. For instance, the first word of
the message did not contain -28, or the subsystem received an event message when it
expected a command. Check that the command is a properly formatted SPI buffer.
Error 60: Process Does Not Have Server Open
The management process rejected an SPI command because the requester process
did not have the management process open. The target process might have been
restarted since the requester opened it. Close the management process and reopen it.
Resetting the Buffer
After checking for file-system errors, your application should reset the response buffer.
To do this, use the special SSPUT operation ZSPI-TKN-RESET-BUFFER described in
Section 3, The SPI Procedures
. This operation resets the positioning pointers used to
extract tokens from the buffer, clears the last SPI error reported in operating on the
buffer, and changes the buffer-length field in the buffer to the length declared by your
application. The buffer length declared by your application can be, and usually is,
different from the buffer length declared by the server.
If your application’s buffer length specified to the reset-buffer operation is less than the
length of the response (the used length of the buffer), your own data following the
buffer is protected, but the excess information at the end of the response is lost. This
situation is sometimes called a “short read.” In this case, SPI returns a “buffer full” error
(SPI error -5), and subsequent calls to SPI procedures for that buffer returns an “invalid
buffer” error (SPI error -1). If error -5 results from the reset-buffer operation, declare a
buffer at least as large as the size recommended by the subsystem.
Resetting the buffer also protects against problems that can occur if your application’s
buffer is shorter than the server’s buffer. If you do not reset the buffer, your own data
following the buffer might be overwritten as you extract tokens from the buffer, even if
the reply’s used length is short enough and no response data is lost. (SSGET calls are
not guaranteed not to change the buffer or increase its size.)
Checking the Response Buffer for Errors and Warnings
NonStop Kernel subsystems report most command errors and command warnings in
the form of tokens in the response buffer, rather than as file-system errors. An error is
a condition that causes the command to fail. A warning is a less serious condition that
can be significant to the application, but does not cause the command to fail. Errors
and warnings can be present in the response even if the file-system error value is zero.
After checking for file-system errors and resetting the buffer, your application should
check the return token and (optionally) check any error lists. For further information,
see Errors and Warnings
on page 2-47.