Re: %EOF, %FOUND and the infamous Dow loop -- RPG400-L

Joe,

>Even the simplest Java IDEs support showing the results of a function, but
>that's really not the discussion here.

I agree the ability to display the results of an ad hoc call to a function from
a command line is useful during debugging.  I especially like it in other IDEs
for testing new functions I write, where I want to just pass it various argument
extremes and examine the results or trace the program execution.

But as we both know, STRDBG does not support that so I wouldn't expect it to
support any BIFs either.

>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.

But the same argument can be made for any code you encapulate behind a function.
Prior to using a function, you had all these global variables you could examine
and alter.  Create a set of service programs with collections of useful
routines, and you lose the ability to examine some of that.

Maybe a bad analogy since you can step into your own function but not a BIF, and
the BIFs in question for db I/O status are not part of the actual db I/O.  My
point was simply that we have similar issues with any function call  - you can't
evalutate the result from a command line, and if you use it in an expression
instead of assigning it to a variable, you can't readily see the result at a
breakpoint either.

>Requiring dummy code to test a program is absolutely wrong,

It isn't my preference either.  It is just an alternative I have seen mentioned
in the past when this has been brought up.  I would prefer the INFDS.

>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?

In the first place, I don't see this as being that big a deal.  I can generally
tell from from the program flow whether it succedded.  Or by displaying the
contents of the key field(s) for the file in question, and see if they match
what was expected if I am at some other breakpoint instead of in single-step
mode.

Truth be told, I probably don't even use the debugger as often as many people

>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 see a problem with adding an INFDS.  As I understand it, the INFDS
always exists anyway because it is used internally.  The only difference is that
by adding the F-spec keyword and the DS, you get access to it too instead of
just the compiler.

Just keep an external file definition with the INFDS layout, then use the
Prefix() keyword on the D spec where you declare the INFDS for the file.  This
makes for a very simple way to expose the INFDS for any file you like, and I
don't think it makes *any* difference in program size or execution speed.  (The
program status data structure is another story -- coding that can result in
overhead for populating the DS.  But even so that is probably trivial in the big
picture.)

>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.

I rarely single-step either, but it is not uncommon for me to set a breakpoint
on the line following an I/O operation.  One single step will generally then
tell me if it was successful, and that is faster then displaying the contents of
an indicator.  Or sometimes I will just set the breakpoints with the code block
which deals with successful or unsuccessful I/O and I know the result when the
program breaks.

In practice, I just haven't found it to be a big deal.  Or at least not any more
than not being able to display the return value of user-defined functions too.
(I admit I enjoy that ability in other IDEs)

>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.

As I said, it works basically that way for me.  Set the breakpoint immediately
after the opcode, and when it breaks just do a quick single-step to see where it
goes.  (In my coding style, there is normally an IF test or loop condition or
such immediately after an I/O operation.)

Or I just set the breakpoint *within* the conditional code instead of
immediately after the I/O operation.  Then I know as soon as it breaks.

Either way, it is faster for me than displaying the contents of an indicator.

Where's the beef?

>It really wouldn't have taken that long to figure out a way to show the results
>of those particular BIFs.

Nor does it seem hard to make an ever so slight modification to the way you use
debug.  It sounds like you set breakpoints like I do -- just after an I/O.  I
can single step faster than displaying an indicator, or simply move the
breakpoint.   Either way I don't feel like I've really lost anything.

And the INFDS still seems like a viable option if you want to tell when you are
at other breakpoints.  The Prefix() keyword makes external definitions for stuff
like the INFDS trivial to implement.

>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.

It doesn't change my debugging style.  I just use F10 to single-step instead of
F9 and Enter to display an indicator -- that it, assuming I had recently
displayed the indicator.

Maybe it seems like less of a deal to me because I often found it easier to
perform the one single-step or set the breakpoints just beyond the I/O even when
I used indicators.  I don't like to bother to cursor or mouse to an indicator to
display the value, or type out an EVAL on the command line when a quick F10
tells me the same thing...

Doug