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

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-44
Determining How Many Response Records Fit in a
Buffer
Assume that the server builds the response record in the buffer during the course of
executing the command on each object, and assume that the server knows a definite
limit on the size of every possible response record. Before starting execution of the
command on the next object, the server must determine whether the space left in the
buffer is sufficient for the largest possible response record plus the largest possible
context token. If there is not enough space, the server should construct a context
token, put it in the buffer, and send the response.
The situation is more complex if the server cannot put a definite limit on the size of a
response record. One way the server could proceed is:
•
Before starting the operation on the next object, perform a test as in the previous
case, using the expected length of the response record. If it there appears to be
enough space, begin working on the next object.
•
While performing the command, before adding each error list or regular response
token to the response, record the current position in the buffer.
•
After adding the token or error list, determine whether the length remaining in the
buffer is enough to hold a minimal error list, a return token, an end-list token, and a
context token.
•
If there is enough space, continue processing.
•
If there is not enough space, reposition to the last saved position; flush the
data; insert the minimal error list; insert the return token, the end-list token, and
the context token; and send the response.
The minimal error list should contain a subsystem-defined error number indicating that
the response was truncated because it was larger than estimated, and the object name
whose response overflowed. This approach sacrifices some information if it runs out of
space, but always lets the requester know approximately what happened.
Here is a pseudocode example to show how this approach might be implemented. The
lines marked with “*” are the ones needed to handle the case of an unexpectedly long
response. The other lines would be needed in any case.
cmd-xxxxx: ! beginning of code for a particular command
response-need := estimated max size of response
+ size of this command's context;
overflow-need := size of overflow error list *
+ size of ZSPI-TKN-RETCODE *
+ size of ZSPI-TKN-ENDLIST *
+ size of this command's context; *
num-responses := 0;
multiple-responses := MAXRESP <> 0;
if MAXRESP = 0 then MAXRESP := 1;
and other setup needed;
next-obj-loop:
current-retcode := 0;
find next object;
if no next object then go to done;
if ZSPI-TKN-BUFLEN - ZSPI-TKN-USEDLEN < response-need