.MH "Errors"
[cc]mc |
.bq
.pp
Although the Software Tools Subsystem provides a very nice program
development and applications environment, Murphy's Law indicates
that things will still go wrong. "To err is human...", so it is
best to anticipate errors, and know what to do when you
encounter them.  This section indicates some of the more common
causes of errors, and what to do when you encounter them.
The non-technical user can probably skip this section.
.eq
[cc]mc
.SH "Recovering from Errors"
Everyone encounters errors sometimes.  Eventually you will
divide by zero, or try to execute source code, or do something
even worse.  Primos will make you pay for
little mistakes like this, and typically will kick you out of
the Subsystem.
Although graceful recovery is sometimes possible, more often than not, it
is so tedious that it is easier just to start all over
again.
.pp
When an error occurs, and after you have satisfied yourself
reasonably well as to why,
the "cure-all" for Subsystem problems is simply to type:
.be
[bf swt]
.ee
.pp
[cc]mc |
Sometimes, this will not work.  The stack may screwed up,
or something else may have gone terribly wrong.
To clear everything completely, and restart the Subsystem,
type the following:
.be
OK, [bf rls -all]
OK, [bf dels all]
OK, [bf swt]
.ee
.pp
[cc]mc
All error messages that cause an exit to Primos (signalled by
the "OK," or "ER!"
prompts) are briefly explained in appendix A-4 of
the Prime Fortran Programmer's Guide (FDR3057).
Some very common programming
errors can cause cryptic error messages
with explanations that may be unintelligible to the novice.
The rest of this section contains a brief description of
some of those messages.  You need not read what follows
if you don't make programming errors.
.pp
Many Primos error messages are dead giveaways of program errors.
Messages that begin with four asterisks are from the Fortran runtime
packages -- they usually indicate such things as division by zero
or extraction of the square root of a negative number.  For example,
.be
**** SQRT -- ARGUMENT < 0
OK,
.ee
results from extracting the square root of a number less than zero.
.pp
Other more mysterious error messages can also be caused by simple
program errors.
.be
POINTER FAULT
.ee
usually indicates that a subprogram was called that was not
included in the object file.  An obvious indication of a
missing subprogram is the failure to get the
.be
LOAD COMPLETE
.ee
message from 'ld'.
(Note that the Fortran compiler treats references to undimensioned
arrays as function calls!)
A more insidious cause of the "POINTER FAULT" message is
referencing in a subprogram an argument that was not supplied in
the subprogram call;
e.g., the calling routine specifies three arguments
and the called routine expects four.  The error occurs when
the unspecified argument is
.ul
referenced in the subprogram,
not during the subprogram call.
.be 4
ACCESS VIOLATION
ILLEGAL INSTRUCTION AT <address>
ILLEGAL SEGNO
PROGRAM HALT AT <address>
.ee
all can result from a subscript exceeding its bounds.
Because the program may have destroyed part of itself,
the memory addresses sometimes given may well be meaningless.
.pp
To find errors such as these, time can often be saved by using
a program trace.
In addition to the manual insertion of 'print' statements in the
source program, both 'rp' and 'fc' have options to produce a
program trace.  The "-t" option will cause 'rp' to insert
code to trace the entry and exit of subprograms.  (One should
note that only subprograms preprocessed with the "-t" option
will be traced.)  'Fc' will emit code
to produce a Fortran statement-label
and assignment trace when called with the "-t" option.  Although
this trace will contain the statement labels generated by 'rp',
the intermediate Fortran code may be listed and the execution
path followed.
[cc]mc |
.pp
See the subsection on debugging in the Application Notes section of the
.ul
User's Guide for the Ratfor Preprocessor
for more suggestions on finding and eliminating errors in
your ratfor programs.
[cc]mc