WATCH points sometimes don't break debugging RPG ILE
Austin
point works and the debug will break into the program every time a
watched variable changes, or it never breaks and just keeps going no
matter how much the value stored in the watched variable (memory
address) changes.
The variable is declared in ProgramA and passed to ProgramB who also
declares it and passes it to ProgramC. All 3 programs can change the
variable. All 3 programs are in the same activation group.
I allowed the program set to call down into ProgramC. I added a watch
to the variable in ProgramC and then 'work with watch' to see the
memory address. I then removed the watch and went to ProgramB using
the <F14> option (i.e. no code runs) and put a watch there and noted
it had the same memory address. I removed the watch again and <F14>
back to ProgramA and set the watch. Again, the same memory address.
So it shouldn't be an issue of not watching the right address/
variable.
The code goes nowhere beyond Programs A, B, and C, for we are in a
display loop interacting with the user.
This issue comes up from time to time and I have asked a few people
who all respond 'that is a really good question, I have had it happen
as well' but nobody knows why.
As a side note, there are times where the system breaks on a watch all
over the place, seeming to break too often and on the wrong variable,
but that simply seems to be the system reusing the same memory address
ranges and all debug knows is the value stored there changed, even
though it isn't currently assigned to the variable you were wanting to
keep an eye on. This memory address issues doesn't seem to be the
problem here, but I don't know that for sure.
Jonathan Bailey
I think I have had problems like this in the past when re-compiling
programs & removing/adding modules from debug instead of ending debug
then re-starting it.
I dont remember the last time it happened ot me but years ago I added
SEU options to start debug on a program with the name of the source
member & dont often use watches anyway, Its a pain to re-add your
breaks if you have many modules I suppose.
Jonathan.
Austin
Yes, I'm trying to watch the variable in question as I don't want to
have to reset upwards of 50 different breakpoints each time I make a
change. Thanks for pointing out the 'restart debug' thing, as I
didn't mention details on that.
To clarify, this issue on this A to B to C example is one of the times
where the watch point never breaks. No matter how many times I
recompile, etc. And since I am testing changes, I recompile all 3
programs every time and always restart debug. But I can't get the
watch to work for this variable. I have tried setting it in A,
nothing, in B with same results, and again with C. The value of the
80a text stored in the memory address changes but no watch hits.
ProgramA is actually a module, so it could be said ModuleA of multi-
module ProgramA calls basic ProgramB calls basic ProgramC, the
variable in question being passed down from ModuleA to B to C and all
the way back, being used for messaging to track what happens to a
value being computed so we can relate that back to the user.
I'm using the iSeries debugger and SEU. Not sure if WebSphere has an
alternate way of debugging or not, but I don't use WebSphere and will
shortly be transfered to a C# environment/project, so have no reason
to start with WebSphere now. I'm well past needing to use the watch
function now, as I have already fixed the issue, but as this happens
to me and many others I have spoken to from time to time I would like
to figure out this quirk of the iSeries.
Graybeard
>
> - Show quoted text -
I understand that you don't need it now, but fwiw,
The iseries debugger that runs with RSE will allow you to keep
breakpoints with the source. So the next time you need to debug, the
breakpoints are still there.