IV.	Known anomolous behavior.
 
	There are many cases where FDT does not behave as you might guess.
These cases fall into four categories:  effects due to compiler optimization,
effects due to inaccessable information, bugs -- known and unknown, and
restrictions.  These are described below.
 
	Effects due to compiler optimization.
	-------------------------------------
 
	The FORTRAN IV-Plus compiler is an optimizing compiler.  This means
that the compiler translates your FORTRAN program into machine language
in "blocks" rather than line by line.  A block is generally more than one line.
This makes your program run faster, but it also means that within blocks,
the state of variables may not be determined from looking at your FORTRAN
code.  For example, suppose your program contains the following three lines:
		0001		A = 1.0
		  .  .  .  .  .  .  .
		0113		A = A + 1.0
		0114		A = A * B
If you place a breakpoint at line number 114, the value of A will probably
be displayed as 1.0, and not as 2.0.  Further, if you modify the value
of A at that point, it will probably not take effect.  The reason for this
is apparent when you look at how an optimizing and a non-optimizing compiler
translate this code:
	FORTRAN		Non-optimizer		Optimizer
	--------------	----------------------	--------------------------
	A = 1.0		Move 1.0 to A.		Move 1.0 to A.
	A = A + 1.0	Move A to register.	Move A to register.
			Add one to register.	Add one to register.
			Move register to A.
	A = A * B	Move A to register.
			Multiply register by B.	Multiply register by B.
			Move register to A.	  .  .  .  .  .  .  .
						Move register to A.
	Since FDT has no way of knowing that A is not in its niche when the
breakpoint occurs, FDT will read the old value (1.0) from A's location, and
will put any requested modifications in A's location -- which is about to be
overwritten.
	Therefore, if you set breakpoints by statement number, variables
which have recently been modified may be in this limbo state.  Where possible,
therefore, it is preferable to assign breakpoints at the beginning of a
compiler optimization block.  Blocks always begin after an entry point, and
will also generally begin at any statement number which can be referenced
by FDT (see your .STL listing).  Blocks will also generally begin following
the return from a subroutine.
	If this is a major problem, you may try the undocumented /OP:0 switch,
which limits program optimization by the compiler.  This may or may not solve
your problem.
 
	In certain rare instances (only, I believe, in modules with ENTRY
statements), some arguments may be unavailable until the first executable
statement following the entry point.  Thus, examination of these arguments
from a breakpoint at the entry point (or in the type declarations following
the first entry point), will either cause an error, or cause the argument
from the last call to be used.  To be safe, if the module has any ENTRY
statements, and you wish to examine the arguments after the entry point,
place the breakpoint on the first executable statement.
 
	Effects of insufficient data.
	-----------------------------
 
	All of FDT's information is extracted from your list files and the
map file.  Any information known to the compiler, but not listed is
not available to FDT.  This causes one major headache.  When you use
variable dimensions in a subroutine, FDT is aware of how many subscripts
there are, but does not know their size.  It therefore assumes the following
for the lower and upper bound of a dimension when variables are used:
		Lower bound = 1.
		Upper bound = Lower bound.
	Arrays can still be stepped through beyond their upper boundary, but
you must specify a legal value.  This is also true when you use a dummy
dimension of 1.
	Experiment with it, and this will become clearer.

	Virtual arrays which are arguments to a subroutine are inaccessible
through the subroutine.  This is because the list file provides insufficient
information to properly address them.  DEC has promised, in an SPR response,
to remedy this fault in the list format, so later versions of FDT may have this
corrected.
 
	Bugs.
	-----
 
	There are no known bugs in FDT.
 
	If you find bugs, please report them to:
		Robert K. Stodola
		The Institute for Cancer Research
		7701 Burholme Ave.
		Philadelphia, PA   19111
			215 728-2760
Specifically, if the FDT program bombs or generates error messages, send
me a copy of the listings and the map file.  Barring variable modification
and jumping using the G command, FDT should never cause your program
to behave differently.
 
	Restrictions.
	-------------
 
	You may not examine or modify values from a breakpoint in a
function subprogram called from a write statement.
	If you use a PROGRAM statement, the program module have that name.
When you first enter FDT (by running the program), it assumes it is in
a module named .MAIN. (the default program module name).  When referencing
variables or locations in the main module, you must specify the module
name.  After the first breakpoint, it will, however, always have the
correct default module name.
	Entry to FDT through the trace trap mechanism (ie. CONTINUE/DEBUG)
will only allow you to set and clear breakpoints and to return (";G").
	Virtual array access is restricted to VFDT.