Three types of errors can occur when an intrinsic is executed:
Condition code errors. Such errors are generally recoverable
since control returns to the calling program. The operating system maintains
condition codes to provide backward compatibility with previous
(MPE V/E-based) operating systems.
Status parameter errors. When you include the status parameter
in the intrinsic call, it returns status information to the calling routine.
For some intrinsics, both the condition
code and the special status parameter can return information;
other intrinsics use only one of these to return information.
Abort errors. Such errors occur when a calling program passes illegal
parameters to an intrinsic or does not have the required
capability for the intrinsic. An abort error terminates the
process.
Condition Code Errors |
 |
Some intrinsics have an associated condition code. A condition
code is a temporary value providing information about what happened
during execution. The condition code is affected by many intrinsics
and should be checked immediately upon return from an intrinsic.
A condition code has three possible values (CCG, CCL, or CCE)
and has the general meaning as indicated in Table 2-3 “Condition Code Descriptions”. Specific
meanings are listed under the individual intrinsic called.
Table 2-3 Condition Code Descriptions
| Value | Condition Code | Description
|
|---|
| 0 | CCG (>) | Condition Code Greater Than. A warning or special
condition occurred but may not have affected the execution of the request.
(For example, the request was executed, but default values were assumed
as intrinsic call parameters.)
|
| 1 | CCL (<) | Condition Code Less Than. The request was not granted, but
the error condition may be recoverable.
|
| 2 | CCE (=) | Condition Code Equal. Generally indicates that the
request was granted.
|
Status Parameter Errors |
|
Some intrinsics use the status parameter to return
information on the status of the intrinsic call. This parameter
is a native mode (NM) implementation of the condition code feature
with extended capabilities. The status parameter is a 32-bit
signed integer value passed by reference.
|
| |
|
 | NOTE: It is good programming practice to specify the status parameter
and check its value after an intrinsic call. If an error or warning
condition is encountered and the status parameter was not specified,
the intrinsic causes the calling process to abort. |
|
| |
|
The status parameter is read in two 16-bit fields:
| | Bits | Value/Meaning |
|---|
| | 16:16 | status.subsys: identifies the subsystem that initiated the error or warning. |
| | 0:16 | status.info: identifies the type of error or warning. Refer to each intrinsic for possible values.
|
Table 2-4 “Status.subsys Parameter Identifiers” and Table 2-5 “Status.info Parameter Identifiers” represent the possible values
returned by the status parameter.
Table 2-4 Status.subsys Parameter Identifiers
| Subsystem ID | Subsystem |
|---|
| 0 | Successful (no errors) |
| 9 | CM Loader |
| 098 | System Aborts |
| 100 | Switch |
| 101 | Memory Manager |
| 102 | Process Manager |
| 103 | Stack Unwind |
| 104 | NM Loader |
| 107 | Virtual Space Management |
| 108 | Table Management |
| 110 | Clock/Timer Manager |
| 111 | High-Level I/O |
| 113 | Low-Level I/O |
| 114 | HP-IO Channel Manager |
| 116 | HP-IB Adapter Manager |
| 121 | CS80 Disk Manager |
| 122 | Port (IPC) Facility |
| 123 | Dispatcher |
| 127 | CIPER Device Manager |
| 128 | Terminal I/O Manager for Logging |
| 130 | Page Printer Device Manager |
| 133 | Measurement Interface |
| 143 | File System |
| 145 | Secondary Storage Management |
| 151 | Transaction Management |
| 153 | File System Label Management |
| 154 | CM Support Routines |
| 155 | Job and Session |
| 158 | Break Handling |
| 161 | Command Interpreter |
| 165 | Debug Low-Level Breakpoint Management |
| 169 | CM Debugger |
| 185 | File System Storage Management |
| 187 | Error Management |
| 188 | CM Emulator, Translator, OCT |
| 193 | Floating-Point Conversion |
| 195 | Hewlett-Packard SORT |
| 196 | Hewlett-Packard MERGE |
| 198 | Eagle A-MUX Device Manager |
| 200 | U-Code Trap Handler |
| 201 | Data Communication Buffer Manager |
| 206 | System Logging |
| 213 | I/O Services |
| 221 | Intrinsic Aborts |
| 222 | Intrinsic Names
|
Table 2-5 Status.info Parameter Identifiers
| Value | Description |
|---|
| 0 | Normal |
| <0 | Indicates an error condition |
| >0 | Indicates a warning condition
|
Abort Errors |
|
Software traps are interrupts generated by software events in which
the operating system interrupts the normal flow of a process' execution.
Some intrinsics generate a software trap when they detect certain error
conditions. Normally, if an intrinsic causes a trap, the system
trap handler aborts the user program. However, you can write
a procedure to handle abort errors and use it in place of
the default system trap handler, which will permit recovery from errors in
certain cases. For more information on handling traps, refer
to Trap Handling Programmer's Guide (32650-90026).
When a program is aborted in a batch job, the operating system removes
the job from the system unless you precede the command that caused the error
with a CONTINUE command. If the program is aborted in an interactive
session, the system returns control to the parent process.
