Error Detection

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:

The decision to abort a process can be made by:

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:

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:

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.