HP 3000 Manuals HP 3000 Manuals
Error Detection
The types of errors that can occur on the MPE/iX operating system are in
the categories given below, along with suggested actions:
Command Interpreter Errors
Errors in using Command Interpreter (CI) are usually the simplest errors
to detect. They include typing errors and syntax mistakes. For
correcting typing errors, use the :REDO command. For syntax errors or
misunderstandings in how the command works, use the :HELP command or
refer to the MPE/iX Commands Reference Manual Volumes 1 and 2
(32650-90003 and 32650-90364).
File System Errors
File System errors are common at all levels of user interface because
file access affects almost every kind of operation. When you are unable
to open, access, or close a file, consider the rules governing the file's
domain, access, and security. For detailed information, refer to
Accessing Files Programmer's Guide (32650-90017).
Compiler, Link Editor, and Loader Errors
You may have exceeded a configured system limit with program files; ask
the system manager for information. If a program load fails, it is
probably marked unrunnable, in which case you must link it again or
restore the file.
Unresolved externals do not mark the file unrunnable. If this problem
occurs, check for errors in the subprogram names and XL= names.
Determine if the routines you requested actually reside in the Executable
Libraries you searched.
For errors reported by a compiler, refer to compiler information in the
appropriate language manual.
Run-time Errors
Run-time errors present a challenging problem, frequently causing the
program to end abnormally (abort). To determine the answer to a run-time
error, you must consider the following aspects of the problem:
* What is the cause or source?
* What is the mechanism of the abort?
* What information is provided to help trace and correct the
problem?
* What are typical abort situations?
The decision to abort a process can be made by:
* User program
* Library routine
* MPE/iX intrinsic
* MPE/iX operating system
A program's design can cause it to abort if bad input or some
unrecoverable situation occurs. The program can call the QUIT intrinsic
or an equivalent compiler-determined statement. In this case, the
unrecoverable situation is by design; the programmer must provide code to
handle the problem or abort the program.
A process can abort because a subsystem library routine encountered a
problem. For example, if an HP FORTRAN 77/iX program performs a READ
statement, an HP FORTRAN 77/iX library routine is called to perform the
necessary I/O. If an end-of-file condition is encountered, a data format
problem occurs. If the library routine cannot complete the operation, it
may abort the program.
An MPE/iX intrinsic can abort a program, depending on the individual
intrinsic's requirements. For example, it may encounter a missing
parameter, an unusable parameter value, or an unusable address. The
intrinsic might require that the program file have a special capability
to use the intrinsic.
900 Series HP 3000 hardware or software can detect errors. For example,
if an arithmetic operation exceeds a data value maximum, computer
hardware detects an overflow problem. It may also detect a bad
instruction or invalid address for code or data. MPE/iX aborts a program
when a stack requires more room than is available. This alerts you to a
potential problem with recursive calls and loops.
Abort Message Information
When MPE/iX carries out an abort for any reason, the process must
terminate cleanly (complete the operations it would have completed if it
had ended normally). However, because the termination is unexpected,
information may be lost. For example, NEW files may not be retained. A
message indicating the type of abort is printed before termination.
After termination, Command Interpreter prints the final message line.
The information in the message helps to identify the cause and guide you
toward a solution to the problem.
An abort message appears in a standard format providing:
* Program file name
* Location at which the abort occurred in the program file
* Message text describing the type of abort
If the abort occurred during execution of an intrinsic, a subsystem
library routine, or a user library routine, then the location is given
within the appropriate routine and the program file location indicates
the location from which the routine was called in the user's program.
For detailed information on reading an abort message, refer to MPE/iX
Intrinsics Reference Manual (32650-90028)| or the MPE/iX Commands
Reference Manual Volumes 1 and 2 (32650-90003 and 32650-90364).
Typical Causes of Program Aborts
Two causes of abort that occur frequently are data memory protection
traps and aborts in library routines.
A data memory protection trap occurs when a program attempts to address
outside the bounds of the code/data area. This can be caused by a faulty
address or index used for a subscript. For example, a parameter address
may be passed as a byte address, rather than a word-aligned address
expected by the called routine. Address corruption can occur if an array
subscript goes out of the bounds of the array, but is still inside the
bounds of the stack.
When an abort occurs in a library routine, the problem is most frequently
in the user program. Examine the program for file equations that you may
have overlooked. It is possible, although considerably less frequent,
that a bug actually exists in the library routine itself.
File Information Display (Tombstone)
It is frequently necessary to obtain status information on a file to
determine the cause of an error. A file information display is
frequently called a tombstone. It provides:
* Actual physical and operational file characteristics.
* Current file information, pertaining to end of file, record
pointer, and logical and physical transfer count.
* Information on the last error for the file and the last HPFOPEN or
FOPEN error.
When a file is opened, the final characteristics may be different from
those originally requested because of defaults, overrides, :FILE
commands, and the file label.
You can use the PRINTFILEINFO intrinsic to print a tombstone. It
requires that you specify the file number returned when the file is
opened by HPFOPEN or FOPEN. The tombstone can display either a full or
short format. If the file is open, it provides a full display.
Otherwise, it provides a short display. Calling this intrinsic does not
automatically abort the program.
You can call the PRINTFILEINFO intrinsic from programs written in COBOL
II/XL and HP FORTRAN 77/iX. When calling from COBOL II/XL, use the FD
filename. You can call the name PRINTFILEINFO directly from HP FORTRAN
77/iX programs. You can obtain the required file number by using the
FNUM intrinsic.