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



> From: Douglas Handy
>
> I see your point, but just don't see the lack of visibililty as a
> big deal.

No biggie.  We can agree to disagree on this one, Doug!  Really!  I don't
need to be right all the time!  Honest!  Ask my wife!  She makes sure I know
I'm not always right!  <LOL>

> >From your original post the other day, you didn't even seem
> aware of it yet and so were arguing from a theory viewpoint.

Interestingly enough, I wouldn't have made an issue of it except that I was
trying to test something.  I know you'll think this is trivial, but here's
what happened.  I couldn't get the following code to work:

     CHAIN
     DOW     (%found or not %eof)
  (process)
     READE
     ENDDO

I know it's wrong Doug - Simon pointed out that the "or" should be an "and".
But here's the thing: how do I debug this?  Since I have no visibility into
the BIFs, the only way I can test is to change the code and see if it works.
And that, I suspect, is what ticked me off more than anything else.  I hate
"programming 'til it works".


> In your scenario it is only necessary for debugging.  Perhaps this is
> presumptious of
> me, but I figure that means you are already making changes to the program.

Not if it's a data-derived error.  That is, some bad data in a file, or bad
data from a called program.  There are many times when I debug a program
which is not the one that needs to change.  But that's a fairly trivial
issue as opposed to the next one.


> I see absolutely no reason to go through 1000 existing programs
> which do not use
> the BIFs just to add the INFDS.

And on the exact other end of the spectrum, I like to have strict coding
standards.  And adding an INFDS just for debugging goes way against my
grain.


> But if I did, I'd write a
> program to do it for
> me.  This is simple too, change management issues aside.

Given my background, this is what I'd do, too <grin>.  So perhaps you've
answered my question anyway.  As I move to ILE in toto, I may want to put
some new, more up-to-date standards in place.    I never used INFDS before
except on subfiles, perhaps it's time to change that.


> I suspect this throws off way more people than the lack of being
> able to see the
> value of a function during debug.

This final point may be telling.  I may be much less grumpy about this whole
thing after I write a few hundred ILE programs.  I should revisit this whole
thing in three or six months time and see what my feelings are <smile>.



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.