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


  • Subject: Re: R: RPG Indicators
  • From: bmorris@xxxxxxxxxx
  • Date: Thu, 20 Apr 2000 10:11:07 -0400




>Date: Wed, 19 Apr 2000 23:12:52 +0200
>From: Anton_Gombkötö <Gombkoetoe@ASsoft.com>
>
>>From: Jon Paris
>>I believe Hans commented previously that they were looking at ways of
>>making the BIFS "debuggable" in the future.
>
>Maybe there's an "internal" field like for the null indicator that can be
>debugged?
> ...
> Is there? If not, such fields would do!

Sorry, but I don't think there will ever be debuggable values for
the bifs.  Some of the bifs do have associated internal fields
(currently, but maybe not in the future if we find some case that
can only be determined by generated code) and some require generated
code to determine the value.  Even within the same bif, some files
require generated code for the bif and some can use an internal field.

For the bifs that require generated code, a debugger value would only
be reliable after the statement containing that bif had been executed,
and then only if that particular bif had been evaluated.

For example:

1 c            read(e)   file
2 c            if        %error or %eof(file)
3 c            do something
4 c            endif
5 c            do something else

If %error is on, %eof would not be evaluated, so a debugger value for
%eof would be unreliable.

I would never support changing the rules for short-circuit evaluation
under debug, since that would cause other debug-only changes that might
make a program run differently (e.g. if a procedure call was involved in a
conditional statement and the call was made only during debug because
the truth-value of the statement could be determined without the call).

I know how nice debuggable bifs would be.  While I was unit-testing
this enhancement, I sometimes had to temporarily change my test cases,
adding code to save the value of a bif.  If it had been possible to
add debuggable versions of the bifs, I would have done it.

A final personal opinion: using the debugger is good for finding
problems, but the debugger shouldn't should be used as a quick and easy
method for testing.  Permanent self-checking testcases should be created.
The time taken to create testcases is never wasted - if you write a
testcase that specifically tests a section of code and some maintenance
programmer (maybe you) comes along later and messes it up, the test
case will find it immediately.

I guess that wasn't quite my final opinion.  Here's another one: there's
nothing wrong with writing your code so it's easy to debug.  That usually
makes it easy to read (and test) too.  If you really need to know in the
debugger whether it was %error or %eof that took you into a section of
code, then maybe your code would be better with two separate if's.

Barbara Morris


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.