By default the F77 command assumes your input is fixed format. This means that continuation lines are indicated by a non-blank character in column six, statement numbers must be given in columns one to five, and so on. You may choose a different format if you wish (e.g. free format); however, experienced users will tell you it is a better idea to keep your source in standard formatted Fortran form.
Build mode users (those using line numbered input files), must remember to specify the "+lineNumber" option (LNO in batch).
The maximum allowable unit number for read/write is 99.
For read and write statements, unit 05 is defined for reading, unit 06 for printing, and unit 07 for punching. Under TSS, all of these go to or from the terminal. A read without unit number uses unit 41, a print statement uses unit 42, and a punch statement uses unit 43.
By default the TSS F77 command turns on subscript checking and parameter checks, but it is still quite easy for a program to die of "op code fault", "memory fault", etc. because your program scribbled data in the wrong place. Check your subscript usage carefully. If you get the message "fdebug called from wrap", you will find yourself inside an interactive debugger named FDS. Hit carriage return once to get a traceback showing where your program died. FDS provides a number of options to examine your program -- see "expl f77 fds" for details. Typing DONE will get you out of FDS.
Experienced users advise taking the time to run off the FDS documentation. It is easy to use and will save you hours of debugging.
Integer and integer*2 are identical. Logical, logical*1, etc. are identical.
Free format and core-to-core I/O are much the same as in WATFIV. However, be warned that when doing core-to-core I/O to an array, the array will be treated as a series of records.
An odd bug crops up if you redirect unit 06 to a file and if the first I/O on that file turns out to be an error message from the run-time library. In this situation, the program aborts with the cryptic message
no argument or invalid arguments in fib-list for 06
The best solution to this problem is to correct the bug that caused the run-time error. Of course, you didn't get the error message associated with the bug (since that's what caused the problem to begin with), so you may not know what went wrong. Run the program without redirecting 06 to find out what the error is. You can then correct your bug and run your program again with 06 redirected.
This message is often accompanied by a loader warning
"*** non fatal error * ...... loaded previously". The
most common cause of this is having some extra blank lines after
the END statement in your source file. The compiler reads your
real END statement, and finishes compiling the module it was
working on. Then, since it has not reached end of file, it
assumes that the source for another module is still in the file,
and sets up to compile it. When it reaches the real end of file,
it complains, pretends that it found the END statement that any
Fortran source should end with, and wraps up the module it is now
working on. Since it hasn't seen a FUNCTION, SUBROUTINE, or BLOCK
DATA statement, it concludes that this must be a mainline, and
generates a Fortran mainline object module. Fortran mainlines
have a loader name of "......". If the source contained
a real mainline you will get the complaint from the loader about
"......", since it has 2 separate object modules both
claiming to be "......".
Copyright © 1996, Thinkage Ltd.