RE: %EOF, %FOUND and the infamous Dow loop

> From: Douglas Handy
>
> The basic problem is that the BIF's are *functions*, not data values.  The
> debugger can display the value of any variable, *INxx or
> otherwise, but cannot
> display the value of any function, %BIF or otherwise.

Even the simplest Java IDEs support showing the results of a function, but
that's really not the discussion here.  I understand your contention that a
general ability to show the results of functions is difficult, but to show
the results of the %EOF, %ERROR and %FOUND BIFs wouldn't be difficult at
all.


> Personally, I *like* the new BIFs and eliminating the indicators.
>  For debugging
> purposes, it is more often than not (in my case) used on a simple
> IF or DOW or
> WHEN, etc and single stepping the code makes it obvious whether
> the db I/O was
> successful just by how the program execution flows.

That's fine while you're stepping through code, but sometimes I want to know
the current condition of a variable once I've hit a breakpoint.  With an
indicator, I could, with a BIF I cannot.  What you're suggesting hearkens
back to a time when I couldn't even see the contents of variables, and had
to set a breakpoint at every condition point in order to determine what was
happening in the program.


> And for cases where you have compound expressions so can't tell
> by a simple
> program flow single step, you can either examine the INFDS or
> create a dummy
> variable for testing and set it like:
>
>       Chain
>       Eval    Dummy = %found()
>       If      %found() And FooBar() = 3.14159
>
> then remove the Dummy line after debugging.

Requiring dummy code to test a program is absolutely wrong, because that
means I either leave dummy variables in my program (inefficient) or I have
to remove them after testing, which means I never put into production actual
tested code.  Either of these is a bad choice, and in fact the latter will
not pass strict auditing procedures.  And using an INFDS is just as bad -
why should I be required to add an INFDS to a program that doesn't use it,
just because the debugger hasn't been upgraded?  What if I had hundreds of
programs that don't use the INFDS - is it your opinion that I should add an
INFDS to them all?


> I *don't* think it is a matter of a couple of hours time to do
> something like
> this to the debugger.

For %EOF, %FOUND and %ERROR it most absolutely is only a couple of hours,
although I'd love to hear someone in IBM tell me it's more.  Then I'd like
to do some consulting work for that particularly department.


> The times I have used it and needed to debug, single stepping
> works for me.

Single stepping is not practical in all cases.  In fact, I rarely
single-step during debugging, except when learning a new piece of code.  For
code I am familiar with, setting breakpoints is far more preferable and
productive.


> How is it that not being able to display the result of a BIF is
> "taking away
> functionality"?

The loss of functionality is not purely the issue of the BIF, Doug.  It's
the fact that, before the BIFs were available, I would write an I/O opcode,
set a breakpoint immediately after the opcode, and be able to immediately
determine the results of the operation without having to step through other
code.  With the new coding style, I am told to stop using indicators, and
use BIFs instead, but now I can no longer execute that same procedure.

A small thing perhaps, but it's the general idea that changes are being made
with little regard for the impact on those of us who use the tools.  It
really wouldn't have taken that long to figure out a way to show the results
of those particular BIFs.

This is my opinion, clearly, and you may not share it.  But I think it's
kind of annoying that I need to change my development style unnecessarily.
This isn't like the change in mindset required to move from procedural to
OO, this is simply the fact that IBM decided to change the preferred syntax
of the language but didn't update the debugger to keep up with it.  That's a
mismanaged resource allocation, in my mind.

Joe


Joe