Re: Debug eval RPGLE %BIFs

Sorry about the lag in response but I had to reload my backup notebook
since my
main one had to go to the repair shop for a week.



boldt@ca.ibm.com wrote:

> Roger Vicker, CCP wrote:
> >Has anyone else tried during a debug session of an RPG/ILE (CRTBNDRPG)
> >program  to eval one of the new file bifs (%EQUAL, %FOUND, %EOF)? I
> >tried this today and the debugger insisted that the Identifier doe not
> >exist. I tried both form %FOUND and %FOUND(FILE). Other bifs used in
> >the program (%ELEM...) can be evalled ok.
> >System is V4R3M0 which means the RPG is V4R2M0, most current cum ptf.
>
> I'm looking at a debug session now, and I get errors when I
> try to do EVAL %ELEM(ARR) or EVAL %SIZE(ARR).  What debugger
> are you using?
>

I'll have to recheck this tomorrow my gray matter cpu may have been
stuttering
also. I've been using DBGVIEW(*SOURCE) and the standard IBM debugger
with
DSPMODSRC. It would be very helpfull in moving to the new BIFS if you
can check them like any other valid field before stepping into a
complex statement using them.

> >I also noticed that a successful CHAIN does not reset the %EOF. I
> >scanned "ILE RPG for AS/400 Reference" for any information on bifs and
> >these particular bifs without finding any mention that this would be
> >normal behavior. It seems to me that if a CHAIN (or SETLL for that
> >matter) that is successful, the file cursor now points to a valid
> >record and therefore the %EOF should be false especially when the
> >INFDS is.
>
> Well, the RPG Reference I'm looking at (on page 364) says:
>
>    %EOF returns '1' if the most recent read operation or write
>    to a subfile ended in an end of file or beginning of file
>    condition; otherwise, it returns '0'.
>
>    The operations that set %EOF are:
>
>    - READ
>    - READC
>    - READE
>    - READP
>    - READPE
>    - WRITE (subfile only)
>
> So this is working as described - %EOF is not affected by
> successful CHAIN or SETLL operations.
>
> This begs the question, though:  Is this what RPG programmers
> expect?  Although this is working as intended, clearly %EOF
> does not reflect the end-of-file status as reflected in the
> INFDS.  Would this be a more reasonable behavior for %EOF?
> Would any working programs be affected if we made this change?
>
> Cheers!  Hans
>
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>

I see some responses that agree with the "working as designed" setup.
My point of
view was some what more centered on the file cursor and the INFDS. I
simply
expected that since the cursor was pointing to a record then the
_FILE_ was not
at %EOF. I understand that the %EOF can be a reference to only the
last read and
that is a valid expectation from the operation function point of view.
As far as
a "CHAIN not resulting in an EOF" I can agree that it shouldn't but
again from
the FILE view it can result in a %NOT(%EOF) if successful. I wonder,
with an
un-successful CHAIN what is the cursor status?

The application of this might be in the combined sequential-by-key and
random
access such as:

key    chain file
        if   %found(file)
        dou  %eof(file)
        ....
key    reade file
        endo
        endif

could be rewritten as:

key    chain  file
    dow    %not(%eof(file))
    ....
    key    reade  file
    enddo

Also, if we want to get picky <grin> then a READE and READPE may or
may not cause
an actual %EOF when the records matching the key are exhausted. If
there are keys
greater than the factor 1 then the READE is not really %EOF but is
%NOT(%FOUND).
Perhaps the "proper" implied structure is that any time the file
cursor points to
a valid record then %NOT(%EOF) and when %EOF occurs it should also set
%NOT(%FOUND)?

Roger Vicker, CCP
--
*** Vicker Programming and Service *** Have bits will byte ***
www.vicker.com ***

Swift's Genuine Irish Bratwurst served here. . . .

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