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

SPI Concepts and Protocol

SPI Programming Manual—427506-006

2-34

Continued Responses

Many subsystems let a single command be applied to multiple objects, in which case

the server returns a separate response record for each object. If the server cannot

return records for all selected objects, either because the buffer is too small or the

requester is using ZSPI-TKN-MAXRESP to limit the number of records that can be

returned, the server stops processing objects and returns the completed records along

with the context token ZSPI-TKN-CONTEXT. That one response message completes

the requester-server interaction from the perspective of the interprocess

communication mechanism (such as the file system), and the requester must send

another command to have the server continue processing the remaining objects.

The requester includes the context token in the followup command to tell the server

where to continue processing. The requester copies the context token from the

previous response message to a duplicate of the original command and sends the

command with context back to the server. The server uses the information that it

stored in the context token to resume processing with the next object.

The use of the context token lets subsystems be context-free—that is, independent of

any processing that occurred before the current command. A context-free server lets

the requester interrupt or abandon the continuation of a series of replies. Most

NonStop Kernel subsystems are context-free. A context-sensitive server retains

information about previous processing. Context-sensitive servers limit or complicate

the requester’s ability to interrupt or abandon continuation. When practical, servers

should be designed to be context-free.

In the continuation command, the command and parameters must be identical to those

sent in the original command; otherwise, the results are unpredictable. Because the

values of some tokens in the response message might not be appropriate for the

continuation command, your application should not reuse the response message.

Instead, the requester should save a copy of the original command message, copy the

context token from the response into the duplicate command, and resend.

This independence between requester and server lets your application alter its course

of action without retrieving all messages. For most subsystems, the application can

issue other commands before issuing the continuation command, or it can abandon the

continuation. A program might want to do this, for instance, to recover from an error or

to display related information obtained from different commands.

In designing your application, consider that changes can occur in the subsystem

environment between response messages. In some cases, it is important to process

response messages for a command quickly and with few interruptions, so continuation

might not be a good choice. In addition, some subsystems with context-sensitive

servers prohibit or restrict continuation. For more information, see the individual

subsystem manuals.

For subsystems that support continuation, the absence of a context token in a

response message indicates the last message in the response. The last response

message can contain a normal response record or an empty response record that

indicates that there are no more objects to process. (An empty response record might