Have your EODAD do
LFI R1,c'EODA'
BR R14
That will not be a record address.
On Thu, 9 May 2024 08:18:57 -0400 David Eisenberg <[email protected]>
wrote:
:>>What are you trying to do?<
:>
:>I'm trying to overcome a limitation in ASMIDF involving single-stepping
through code while debugging. That's the only reason I'm asking about this.
:>
:>As per the IBM documentation, ASMIDF's single-stepping process involves the
automatic placement and removal of breakpoints. To do accomplish that, ASMIDF
must predict the next executable instruction, so that it can set a breakpoint
on it. When the current instruction is a GET macro, ASMIDF doesn't have the
logic to dig out the EODAD and set a temporary breakpoint on that instruction;
it only sets the temporary breakpoint on the instruction immediately following
the GET.
:>
:>My GET code is in an external subroutine that is called by other
applications. Any developer who single-steps into that subroutine never gets
control back from ASMIDF, because the GET loop reads to EOF, and (because there
is no automatic breakpoint set on the EODAD) the program runs to completion
without stopping.
:>
:>The entire problem disappears if the EODAD is immediately after the GET,
because then the breakpoint will be set and honored in all cases. But if I do
it that way, then I have to know whether I reached that instruction because it
really is the EOF, or whether the GET returned a record.
:>
:>I just don't know how to dig what I need out of any control blocks, or
whether that information is available. Does the GET return anything I can use?
Maybe via R1? Or is there something in the DCB to tell me if I've reached the
EOF?
:>
:>David
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
