This section provides you some notes/suggestions you should take into account when using the interactive debugger.
The target application should be a 32-bit application.
When the debugger interrupts execution of a Windows application, it stops that application's processing. Therefore, it cannot refresh the displays on its windows. If you want to inspect their current states, arrange your windows so the application windows are always visible.
The Line Command window keeps up to about 5,000 lines of command results.
You can specify statement identification numbers in two different ways: editor line numbers or relative line numbers. You can only use both methods when debugging programs compiled with the NUMBER option. Programs compiled with NONUMBER can only use relative line numbers. To change between using editor line numbers and relative line numbers, you can either use the ENV line command, or the Option, Environments, Input dialog box.
When a program which has duplicate numbers consecutively in the sequence number area is compiled with the NUMBER compiler option, you might not be able to set a breakpoint where you want, if you have specified the editor line number as a statement identification number. To prevent this problem, select the relative line number as statement identification number, or recompile your program with the compiler option NONUMBER specified to prepare for debugging. (Better yet, renumber the source code before compilation!)
Example
001000 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. MAIN.
:
001000 PROCEDURE DIVISION.
001100 DISPLAY "*** INITIALIZE ***". [1]
001100 MOVE ZERO TO DATA-1. [2]
001100 MOVE ZERO TO DATA-1. [3]
:
003600 END PROGRAM MAIN.In the above example, a breakpoint will be set on the DISPLAY statement ([1]) even if you try to set it at the MOVE statements ([2] and [3]).
You can set breakpoints and passage counts at EXEC SQL in the PROCEDURE DIVISION.
However, you cannot set a breakpoint or a passage count at EXEC SQL including non-execution statements such as the WHENEVER statement.
In addition, you cannot set breakpoints and passage counts directly in embedded SQL statements.
When programs contain the clauses REPLACING, DISJOINING or JOINING, the debugger displays the original source without applying these clauses. If the position of statements or procedure names changes as a result of the source substitutions, it is not possible to debug the programs correctly.
As the COPY statement creates program restrictions, you cannot debug programs correctly in the following cases. The way to avoid this trouble is shown in each case.
Programs including library text containing the following definitions in the COPY statement:
Entire program definitions (from IDENTIFICATION DIVISION to END PROGRAM)
Entire factory definitions (from IDENTIFICATION DIVISION to END FACTORY)
Entire object definitions (from IDENTIFICATION DIVISION to END OBJECT)
Entire method definitions (from IDENTIFICATION DIVISION to END METHOD)
The way to avoid this trouble is to define the statements described in the above library text directly in the program that imports the library text.
Describing the COPY statement in the PROCEDURE DIVISION, and the PERFORM statement is in the end line of the imported library text:
The way to avoid this trouble is to define the CONTINUE statement at the end of the library text.
Describing the COPY statement in the PROCEDURE DIVISION, and the COPY statement is in the end line, and the END PROGRAM statement has not been described:
The way to avoid this trouble is to define the END PROGRAM statement in the program in which the COPY statement has been described.
Describing the COPY statement in the PROCEDURE DIVISION, and the PERFORM statement is in the end line of the imported library text, and the PERFORM statement is immediately after the COPY statement:
The way to avoid this trouble is to define the CONTINUE statement immediately after the library text and the COPY statement.
Describing the COPY statement in the PROCEDURE DIVISION, and the COPY statement is immediately after the EXIT statement, EXIT PROGRAM statement, or EXIT METHOD statement, and the start line of the import library text contains the section-name or paragraph-name:
The way to avoid this trouble is to describe the section-name or the paragraph-name in the program that imports the library text, not in the start line of the library text.
A stored procedure cannot be debugged.
Do not perform the following operations when the debugger is running:
Change a screen setting on [Display Properties].
Change a setting on the Control Panel.
Terminate the Windows system.
Pressing the F12 key in the application window during application execution will generate a signal and interrupt the execution, resumption of which will terminate the application.
The debugger may access a resource such as a file or database while application execution is suspended in the system or COBOL runtime system. If the debugger under this situation is terminated or restarted, the resource may be destroyed. If the debugger is terminated or restarted during synchronous processing in the COBOL runtime system, a runtime message such as JMP0034I-U may be output. If this occurs while a multithread application is being debugged, the probability increases as the number of threads increases. The application must be terminated normally. To ensure safety, a backup copy of the resources used for debugging should be made in advance.
Threads other than the thread that executes the COBOL program might exist, depending on the system, the server application, etc. When such an application is debugged, it is necessary to treat it as a multithread application. For details, refer to "2.6.4 Debugger Compatibility with Multithreading".
The COBOL debugger cannot be used while an application is being debugged using the PowerCOBOL debugger or Visual C++ debugger or is being executed on Systemwalker.
The just-in-time debugging function will not operate if the application itself handles application errors by using an exception handler for structured exception handling. This applies to, for example, applications linked to non-COBOL programs that have an exception handler and applications called from server programs such as a Web server that has an exception handler. To check for application errors that occur in such applications, use the general debugger starting method or debugger starting method of the program to be debugged.
Corrective action you should take if "Execution was terminated before start of program was reached." is displayed is shown below.
The program specified in the debugging start program ended without being executed. Alternatively, there is an error in the specified program name:
Make sure that the debugging start program name is correct.
The program is not a debug target program:
Refer to "2.2 Preparing Programs for Debugging", and then create the program again.
The debugging information file is not found:
The debugging information file is searched for in the folder storing the executable files and dynamic link libraries. If the file exists in a different folder, specify the debugging information file storage folder.