Hi David,
Have you acces to a DEB block ? there is the DEBEOF flag
Just in case...
René
Le jeudi 9 mai 2024 à 04:18:29 UTC+2, David Eisenberg
<[email protected]> a écrit :
Peter,
Yes... I'm using ASMIDF. I can definitely set a manual breakpoint on the EOF
label, and the breakpoint will be honored... but that's not my problem. The
issue pertains to single-stepping; in my case, using IDF's STMTSTEP command.
The code doing the GET resides in an external subroutine that is called by
multiple applications. Suppose the developer is using ASMIDF, and is
single-stepping through his/her application program, and reaches a call to that
subroutine. The developer issues a STMTSTEP command, and quite reasonably
should expect to get control back immediately after the call, but that doesn't
happen. That's because the developer has no idea that he/she needs to set a
breakpoint on an EODAD address inside the external subroutine being called.
ASMIDF itself doesn't set the breakpoint on the EODAD address during
single-stepping. So when the EODAD is reached, ASMIDF simply plows through
execution with no breakpoint set, and the developer never gets control back
until the program terminates.
Hence my original question. The whole problem goes away if the EODAD address
immediately follows the GET (as in my original code snippet) because ASMIDF
does set an automatic temporary breakpoint on that address when
single-stepping. But that solution requires my being able to determine whether
I reached the EODAD address because I *fell into it* (after a successful GET),
or because it was *branched to* as a result of reaching the EOF.
That's why I'm hoping that the GET macro sets something I can test, or perhaps
there's something in the DCB I can examine. I just need to know whether the GET
read a record, or whether it hit the EOF. That would solve the ASMIDF
single-stepping problem entirely.
I hope this makes sense!
David
