Debugger in PDSOE and includes

Hi James,

Have you tried compiling the file with a debug list option and putting the debug list in a location the debugger can reach?  Does this work?

Thanks [mention:3e7a97a476f64c1ba205faa0e27ff59e:e9ed411860ed4f2ba0265705b8793d05] I will give that a go. Is there a way of getting PDSOE to compile with DEBUG-LIST by default?

Hi James, if the debug list doesn't exist the PDSOE debugger should generate a temporary debug listing, which should live in the local working directory (along with any other tempo files).  So this is where the debugger gets the listing file from.  the listing is deleted at the end of the debug session.  But the debug list needs to be on the same machine as where the debugger is running.

I've tried sticking a debug listing into a folder that's available. That doesn't help. All code is local to my machine. I just get a screen up "Source not found" and the option to edit the path. The icode it's looking for is in the path. Interestingly I can't find any temporary debug listings in the working directory.

As a slight aside, is there a standard extension for debug listings?

Hi James, I believe the debug list is generated from the r-code, since you are using Developer Studio and the code is compiled.  In this case it will need to be able to find the source files in the propath.  It might be worth checking your debug configuration to be sure it's configured as you expect?  I tested debugging a simple piece of code in 11.2 and 11.3 and it seemed to work from me.

From the debugging and Troubleshooting manual:

Debug listing generation from r-code

When your application runs an r-code file, OpenEdge attempts to provide the debug

listing for it by searching the PROPATH for the associated source file (.p, .w). The r-code

contains references to all associated source, include, and debug listing files, as well as

its cyclic redundancy check (CRC) value.

If OpenEdge finds the source file associated with an r-code file, it compares the CRC

value of the source file with the corresponding CRC value stored in the r-code. If the

CRC values do not match, OpenEdge displays a warning message and continues

using the file with a bad CRC value.

You can step through r-code for which the source code is unavailable; however, the

Debugger cannot display the source code in the source code pane. In this case, the

Debugger displays the procedure name and line number in the status bar.

I wonder if it's to do with our directory structure? We've had other issues that have been put down to this by Progress. We have separate directories for wcode, icode, pcode etc, and they all compile into a common rcode directory. I might try getting rid of the common rcode directory and just compile into the source directory and see if that helps.

Hi James, it could well be.  Maybe simplify it even more by creating a new test project using all the defaults and then create a simple test, as I did.

Sadly I don't have much control over the directory structure of the source as that is the way it is kept within our source control.

I understand.  If this is the cause then maybe it's best to log a support case so it can be investigated further, and possibly a bug logged?

Yeah I'm going to raise a support case. I'll link it to here. Keeping the rcode in the same directories as the source hasn't solved the problem, although ironically seems to have made things run quicker which is nice!

Case 00279005 raised.

Myself, I think that r-code separation from source is a good thing.   I can't say the same about separating .ps from .is, unless the goal is to eliminate the later.  There is no reason why you would need this for SCC ... in fact, with SCC there is even less reason to have it that way.