× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Joe,

>AGH!  I can't believe this.  This is unacceptable.  I don't quite understand
>when it was that it became acceptable practice to remove functionality when
>moving to a new release, but this is just ridiculous.  ...

>... But how many development hours would it
>have taken to add BIF support to the Eval operation of the debugger.  The
>information is available, it's simply a little extra parsing.  A couple of
>hours, tops, one would think.

I don't look at it as them "taking away functionality", nor do I suspect it
would only be a "couple of hours, tops" to add it to the debugger.

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.

Now what you *can* do is add an INFDS for the file, if you don't already have
one, and have the debugger display the value of the field assigned to *STATUS.

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.

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.

The other thing which may be considered "taken away" is the ability to change
the state of the indicator for the sake of testing alternate program flow paths
(e.g., what happens when the I/O really does fail).  While you could set a
breakpoint and modify a data element like *INxx, it is not reasonable to expect
a debugger to support modifying the result of a *function*.

I *don't* think it is a matter of a couple of hours time to do something like
this to the debugger.  Moreoever, I have yet to really miss it, but I'll grant
I've only just started to use the BIFs because I was stuck on supporting V3R2
compliant source for a long time...

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

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

Doug



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.