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

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-52
Pass-Through Error Lists
contain those items needed to tell what inappropriate condition was detected and
any additional values needed to understand the error.
For example, if a command asks to start a subdevice when the line is not started
and the name of the line is inherent in the name of the subdevice, no additional
information need be included. But if the command asks to start an object and fails
because an attribute of the configuration of the object conflicts with some
information obtained from the device, the item of information obtained from the
device itself would be valuable in understanding the problem and should be
included in the error list.
7. If a description of an error from C is relevant in reporting the error, and if C is
accessed through an SPI interface, the error list B creates must contain a copy of
all the error lists in the error response returned by C.
8. If a description of an error from C is relevant in reporting the error, and if C is not
accessed through an SPI interface, B should follow the directions C provides for
constructing an error list to report errors from C.
Although some details might vary, C defines a token for each item of information
that is important for understanding what C was asked to do and what went wrong.
B forms an error list on behalf of C and nests this error list within the error list B
creates. The ZSPI-TKN-ERROR token in this error list is generally the error status
returned from C. The values of the other tokens are generally the values of the
arguments passed to C if C is a procedure or are similar parts of the command for
other styles of interface. If C defines a token for a parameter B did not use, usually
B omits that token when forming the error list. In some cases, the actual argument
passed to C might not be meaningful to another process (such as a file number),
and in such cases, the directions supplied by C explain what B must do to obtain
an appropriate representation.
When forming an error list on behalf of C, B should make the version portion of C’s
subsystem ID in the ZSPI-TKN-ERROR token be zero. This is to indicate that
because the error was not constructed by C itself, the actual version of C cannot
be determined from the error list.
In all cases, the error number in B’s level of the error list is one defined by B. The
error number might mean simply “I got an error from another subsystem.” It might
be specific to a subsystem: “I got an error from subsystem X.” Or it might have a
meaning in B’s terms and the error list from C is just additional information relevant
to that error. The error number in B’s level never describes C’s error directly.
9. If the error is a problem in the formation of the command to B, such as a missing
required token, an extra or unrecognized token, a too-high server version in a
command, an unrecognized command number, an unrecognized object type
number, or an invalid value in a field of the command, then guidelines 4 through 8
do not apply.
The error list must contain B’s error code for the problem detected and
identification of the token and field causing the problem (except for server version
too high). Include the ZSPI-TKN-PARM-ERR token to describe the token and field.