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
