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

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

JT,

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

>Not as good.

Works for me.  But then what is wrong with using an INFDS (which I often include
anyway) and displaying the value of the *STATUS field?

>I think Joe's saying that the %BIF is less effective than an indicator.
>
>I would think it WOULD take only a couple hours.  They change the
>implementation of the %BIF to us a memory location instead of a register, if
>it's not already that way.

I don't know how it is implemented, but I wouldn't expect it to be in a register
since you can have lots of intermediate statements between the I/O and the BIF.

I suspect a %BIF() with a named file gets the information from the INFDS for
that file (which exists even if you don't name it to make it available to your
program).

I don't know how they implement the BIF without a filename specified.  I suspect
there is some location which gets updated with the last filename accessed. and a
BIF with no name uses this location to decide what INFDS to examine.

But that is all SWAG on my part and could be completely off base.

>You allow both the language and the debugger:  EVAL %BIF = *ON.

Huh?  Why in the world would you want a debugger to SET the return value of a
function?  Only a function should be able to do that...

>If these
>are already stored in memory locations (ie variables) then it's just a
>matter of assigning a value to a named variable.

I haven't tried it, but perhaps you could change the contents of the INFDS and
the BIF would report the new value.  But even if it works, I'm not convinced
this is a good debugging technique.

If you are trying to change the result of an I/O operation to modify program
flow for testing, you are not getting a real-life test anyway because data
fields have been altered.  Far better in my book to use more complete bed of
test data with the extremes and abnormal database conditions so the code gets
executed as a natural process during testing.

>I'll be glad to stand corrected.  But I'd still like to see this fixed.

This must fall in the category of "If it ain't broke, fix it 'till it is!"

I don't see the debugger as broke just because it can't return the result of a
function, nor set the value which will later get returned by a function.  All
you need to do is look at your debugging a little different, and use single-step
mode and/or the INFDS to determine the success of an I/O operation.

What is so hard about that?

Doug