Error Lists
Error lists are Subsystem Programmatic Interface (SPI) buffers returned to an application program
by another process. Error lists can be returned to your application process if you are using SPI to
send requests to another process. If the other process encounters a procedure error, it returns the
error information in an error list to your application process.
Error List Content
Unlike the error messages described elsewhere in this manual, error list information is returned in
the form of tokens that are meaningful to application processes rather than in the form of displayable
text. The content of error lists can vary; for example:
A response record can contain both response data and error or warning information.
A single response record can contain multiple error lists, especially if warnings occur.
A single error can actually be a pass-through error, an error that originated in another
subsystem that was called by the subsystem to which the command was sent.
Figure 1
shows the format of an error list.
Figure 1 Error List Format
The value of the return token, ZSPI-TKN-RETCODE, indicates the content of the error list:
If zero and no error list follows, no error occurred.
If zero but one or more error lists follow, the error lists contain only warning messages: unusual
conditions that might be of interest to the requester but do not prevent the server from completing
the command.
If nonzero, the error list must contain at least one token with an error number that matches the
value of the return token. Each subsystem defines its own set of error numbers.
Error Lists and Non-SPI Subsystems
Some HP software facilities do not have a programmatic command interface based on SPI but do
define standard error lists. If a HP subsystem that has an SPI-based command interface calls one
of these facilities and receives an error, the subsystem usually tries to recover from the error. If that
is not possible, the subsystem reports the error in an SPI error token (ZSPI-TKN-ERROR), embeds it
in an error list of the prescribed form, and encloses this error list in its response.
For information about creating error lists, additional information about tokens and token types,
and definitions of tokens whose names begin with ZSPI-, refer to the SPI Programming Manual.
Traps and Signals
Certain critical problems can cause a process to be unable to continue executing. These are typically
the result of coding errors, but other conditions, such as the lack of a system resource (for example,
memory), can also prevent normal process execution. Such conditions are reported as traps to
TNS processes and as signals to TNS/R native processes.A trap is a software mechanism that
stops process execution.A signal is a software interrupt that can notify a process of other events,
such as timer expiration, as well as of critical error conditions.
The set of signals that are used in the Guardian environment is known as TNS/R native signals.
This set is a subset of a larger set of signals used in the Open System Services (OSS) environment.
Most of the TNS/R native signals are caused by the same conditions that cause traps to occur in
TNS processes. In this manual, equivalent trap and signal conditions are described together.
Error Lists
17
Need help?
Do you have a question about the Guardian Errors and is the answer not in the manual?