The COBOL Debugger displays expanded and changed versions of statements that contain references to items, methods and attributes.
For example:
The PowerCOBOL method call:
CALL CLOSESHEET OF CALL85.
appears as:
CALL "XPOWCSCLOSEMYSELF" USING BY VALUE CALL85.
in the COBOL Debugger.
The PowerCOBOL statement referencing an attribute of an item:
MOVE POW-TEXT OF EDIT1 TO ID-INPUT
appears as:
CALL "XPOWEDITGETTEXT" USING BY VALUE EDIT1 BY REFERENCE POW-0001 MOVE POW-0001 TO ID-INPUT
in the COBOL Debugger.
You handle the expanded statements like any other COBOL statements. You set breakpoints, and view and change data values as if the statements were your own.
Apparently Inactive Code
Debugging any event-based graphical system can appear strange at first if you normally work with procedural code. The debugger can become unresponsive and the application window at times does not refresh itself as you might expect. You find yourself clicking on windows, wondering why nothing is happening.
There are two basic reasons for this behavior:
There are times when the debugger is waiting for an event to come from the application window. At these times only the "Break" button is enabled on the debugger toolbar.
The debugger has stopped the running application (e.g., when a breakpoint has been encountered). There is nothing active to receive and process events from the application window. So clicking on the application window has no apparent effect.
Once you understand why the behavior exists, it is reasonably easy to cope with it.
If the debugger is not responding, look at its toolbar. If only the "Break" button is enabled the debugger is waiting for an event in the application window. You can either switch to the application window and take an appropriate action, or click the "Break" button that may abort the application.
If the user window is not responding, switch to the debugger. The debugger has halted execution for one reason or another. Check the reason, check your breakpoints and restart the execution using one of the Continue menu functions.
Sometimes you want to see the application window at the same time as viewing the code. You do this by sizing and positioning the application and debug windows appropriately.
Using Run to Next Program
Because you are debugging at least two programs (PowerCOBOL and COBOL), and often have many PowerCOBOL generated internal sub-programs, you may choose to use the Run to Next Program function. If you are at the top of the event loop on the EVALUATE POWER--MESSAGE statement, it may appear that nothing is happening. Every time you click on "Run to Next Program" you come back to the same point.
This happens because the PowerCOBOL sheet is receiving several messages from the Windows system. The event loop processes each message. The COBOL Debugger sees the event loop relinquishing control through the EXIT PROGRAM statement and then regaining control when the next message arrives. It therefore appears to the COBOL Debugger that a new program is being executed.
To get to the sub-program of interest you may need to click on "Run to Next Program" several times.
Keeping or Regaining Control
As with any debugging operation, the best way of keeping control is setting breakpoints at appropriate locations in the code.
If the code appears to be running and not hitting the breakpoints you have set, you can use the "Break" function. However, this can cause the application to abort so you have to restart the application.
SVD File Does Not Match Program to be Debugged
If you are experimenting with ways of building the mixed application code together you may encounter a message from the COBOL Debugger that says:
"Debugging information file FILENAME.svd does not match the program to be debugged. The debugging information is ignored."
This can happen when you compile the COBOL code in Project Manager and the rest of the system in PowerCOBOL (or vice versa). To correct this you may need to Build within PowerCOBOL or Rebuild within Project Manager. Rebuild in Project Manager forces a recompilation whereas Build does not.
Another possibility is that somehow one of the systems has lost the compiler "TEST" directive or Compile for Debug option.
