Subsystem Control Point (SCP) Management Programming Manual

SPI Programming Considerations for SCP
Subsystem Control Point (SCP) Management Programming Manual—520619-001
3-4
Command-Message Queueing
assigning it to ZSPI-TKN-MANAGER or ZCOM-TKN-XMGR. Only one ZCOM-TKN-
XMGR token or one ZSPI-TKN-MANAGER token is allowed in a request.
To derive the manager process name from the tokens in the request buffer:
1. If ZCOM-TKN-XMGR appears in the request, SCP uses its value as the identity of the
manager process. Otherwise, the search continues with Step 2. (If there is more than
one XMGR token, or if ZSPI-TKN-MANAGER is also present, the request is
rejected.)
2. If Step 1 fails and ZSPI-TKN-MANAGER appears in the request, SCP uses its value
as the identity of the manager process; otherwise, the search continues with Step 3.
(If there is more than one MANAGER token in the request, or if an XMGR token is
also present, the request is rejected.)
3. If Steps 1 and 2 fail, ZCOM-TKN-OBJNAME appears in the request, and SCP can
extract a name of the form \node.$proc or $proc from the value of its first
occurrence in the buffer, SCP uses this value as the identity of the manager process;
otherwise, the request is rejected.
An application can use any one of these three tokens to specify the name of the SCP
process that should process a command.
Command-Message Queueing
The SCP process opens a communications subsystem when it receives the first valid
command for that subsystem from an application. This open call specifies nowait-
depth as 15, so the SCP process can send as many as 15 command messages to the
subsystem without waiting for a response. If the SCP process receives more than 15
command messages for the subsystem, it queues the additional command messages until
either the subsystem finishes processing a command message or one of the command
messages being processed by the subsystem is canceled. Commands are queued in the
order received. There is a separate queue for each subsystem. Subsystem responses to
these command messages can be in any order.
Command-Message Cancellation
An application can cancel an outstanding command by using the Guardian CANCEL
procedure. When this procedure is called, the file system sends a system message -38 to
the SCP process. The SCP process uses the system message to determine which
command message should be canceled. If the command message has already been
forwarded to a communications subsystem, the SCP process cancels the command. If
the command message is in a queue, it is deleted from the queue. No SPI response is
returned.
All or part of a command might be executed before the command is canceled.
Management applications should inquire about objects that might have been affected by
the command message to determine if more processing is required to recover from the
cancellation.