As mentioned in another thread, some Fortran compilers
have a special DEBUG feature. For each program unit
(main program, subroutine, or function) before the END
statement, you can put a DEBUG statement.

Some options of the DEBUG statement itself allow for
subscript bounds checking for some or all arrays, tracing
of execution of numbered statements, and changes to the
values of some or all variables.

In addition, one can add debugging statements to be
executed at different parts of the program, with all the
statements placed in debug packets, just before the END
statement.

DEBUG
AT 10
DISPLAY X,Y,Z
END

will, just before executing statement 10 print (NAMELIST
like) the values of the indicated variables. You can put most
statements inside a debug packet, so even:

DEBUG
AT 10
GOTO 20

Even worse than a COME FROM statement, there is no sign
at either statement 10 or 20 about what it does.

More usual, you would do something like:

DEBUG
AT 10
TRACE ON
AT 20
TRACE OFF
END

so statement number tracing only happens between
those statements.

Wow. Thought that was long gone. It has been long enough since I used it that my memory might be tainted by time; but I remember that as the best debugging feature ever.

On Tuesday, August 23, 2022 at 7:19:51 PM UTC-7, John wrote:
> Wow. Thought that was long gone. It has been long enough since I used it that my
> memory might be tainted by time; but I remember that as the best debugging feature ever.

Well, Fortran G is still around, but it was only today that I looked it up for VS Fortran.

I never actually got to use VS Fortran, the newest of the Fortran compilers for
OS/360 and its descendants.

I did debug some large programs with WATFIV, which has bounds checking and
undefined variable checking always enabled. (The latter checks for all bytes
containing X'81'. It will fail for CHARACTER*1 with 'a' in it.)

On Wednesday, August 24, 2022 at 11:02:03 AM UTC+10, gah4 wrote:
> As mentioned in another thread, some Fortran compilers
> have a special DEBUG feature. For each program unit
> (main program, subroutine, or function) before the END
> statement, you can put a DEBUG statement.
..
From the beginning, PL/I offered subscript bounds checking,
integer decimal and binary overflow checking, floating-point overflow
checking, division by zero checking, and many others.
All with facility to recover, to print diagnostic information
such as the values of variables.
As well, there was a CHECK option in which variable names
could be included. When the value of a named variable was changed,
PL/I automatically printed the new value.
..
> Some options of the DEBUG statement itself allow for
> subscript bounds checking for some or all arrays, tracing
> of execution of numbered statements, and changes to the
> values of some or all variables.
>
> In addition, one can add debugging statements to be
> executed at different parts of the program, with all the
> statements placed in debug packets, just before the END
> statement.
>
> DEBUG
> AT 10
> DISPLAY X,Y,Z
> END
>
> will, just before executing statement 10 print (NAMELIST
> like) the values of the indicated variables. You can put most
> statements inside a debug packet, so even:
>
> DEBUG
> AT 10
> GOTO 20
>
> Even worse than a COME FROM statement, there is no sign
> at either statement 10 or 20 about what it does.
>
> More usual, you would do something like:
>
> DEBUG
> AT 10
> TRACE ON
> AT 20
> TRACE OFF
> END
>
> so statement number tracing only happens between
> those statements.