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



Paul Cunnane wrote:

>>>I'm trying to see what the 
>>>value of %EOF is while in
>>>debug.
>>
>>Sorry, it can't be done, and it's a bit depressing.  More valuable to me 
>>would be the ability to set/reset these BIFs.  About the only way to deal 
>>with the situation is to use a flag to indicate the value (can you say 
>>indicator?  :-) )
>
>Just curious, why would you ever want to use (say) [eval %eof = *on]?  I 
>don't see any particularly elegant applications for this.
     
For testing the "end of file" path in the code without having to jigger the
data.  Yes, yes I know this is not a Good Idea, but imagine a debugging
session where I have a stupid error and am inadvertently using the wrong key
value.  I'm expecting a "no hit" but because my key is wrong, I get a record
found.  I discover this by looking at the key value used on my READx.  Now
that I've discovered my error, I can:
a) end the debugging session, fix the source, re-compile, re-bind, reset my
test data and try again or
b) continue debugging, set the "EOF" indicator field the way I want and
follow the desired code path.
You're right - there isn't any particularly elegant application for it, but
if I'm in debug, it's usually because I'm very lost.  The ability to eval
%eof = *On (or *Off) works great if you have:

c if %eof
c callp tellUserNoRec(fileName: recordKey: rc)
c else
c callp processGoodRecord(rc)
c endif

>I would define fileAtEOF as an indicator (N), 
>so that later code could use it in the form 
>[if fileAtEOF] without the cumbersome [= 'Y'].

I agree with you completely.  I alluded to that with the wisecrack about
indicators.  The example code was cut from an early program, pre-"N" field.

Buck Calabro
Aptis; Albany, NY
"We are what we repeatedly do.
 Excellence, then, is not an act, but a habit." --Aristotle


Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
+---
| 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.