Re: Strange debug behavior -- WDSCI-L

I don't know. I can debug into the recursively called program, and the stack in the Debug view is correct. But, when I return from the last procedure of the recursive call, the debugger removes everything from the stack rather than just down to the PEP. I think that is where things get confused.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx

-----mlazarus <mlazarus@xxxxxxxx> wrote: -----
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
From: mlazarus <mlazarus@xxxxxxxx>
Date: 12/19/2016 10:12AM
Subject: Re: [WDSCI-L] Strange debug behavior

Mark,

One workaround might be to load the program initially, then duplicate
that same program object into a library higher in your *LIBL (e.g.
QTEMP). The recursive call will then load a different object. I'm
curious if that will work or if the debugger will still get confused,
since it's the same name.

-mark

On 12/19/2016 9:42 AM, Mark Murphy/STAR BASE Consulting Inc. wrote:

It seems that RDi is unable to deal with debugging a program that is called recursively. This is the scenario. Program A is a comment maintenance program. One of the options is that I can load predefined comments, and one of the places I can copy comments from is the comment file that program A is maintaining. The selection prompt to select comments to copy is program A in inquiry mode (since the logic already exists). This causes program A to be called recursively which does indeed work since I set the activation group for program A to *New. This is a fairly complex interaction of recursive calls with callbacks, and I need to debug through it. Unfortunately the debugger seems to get confused, not by the callback, but by the recursive call. When the recursive call returns, the debugger reports that the program being debugged has ended (this is correct), but it doesn't seem to recognize that the same program is also still being debugged via an invocation earlier in the progr

call stack. It does figure it out eventually, but by then it is always way beyond the point which I want to debug, and no combination of break points and stepping methods seems to have any effect.

I really don't expect any solutions here. I just have to go about working through my issues a different way. It is just frustrating when the debugger doesn't function as expected (doesn't stop at breakpoints, or single step when requested). There have been other places where the step modes didn't function as expected, but I just couldn't nail down a way to recreate the issues, for example: F7 Step return does not always return to the call point for the procedure I am in at the time I press F7. This one seems to randomly run through the end of the program, or to a break point.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx