Resume and Execution Options › Control and Resume Execution from a Breakpoint › Jump to Another Location › Debug Optimized Applications

Debug Optimized Applications

CA InterTest for CICS supports the debugging of programs that have been optimized, either by the COBOL compiler's OPTIMIZE option or by CA Optimizer or CA Optimizer/II. However, debugging these programs sometimes results in unexpected behavior.

Note: The PL/I compilers are optimizing compilers.

Often, as part of the optimization process, a compiler will relocate individual instructions, statements, or even entire paragraphs so that the optimized program will run more efficiently. This means that some or all of the instructions generated for a given statement may be moved to another statement, or that some or all of the statements in a paragraph may be moved to another paragraph. When this type of optimization occurs, the resulting object program and corresponding listing may not accurately represent the relationship between the source statements and their generated object code, or even between a paragraph label and the statements contained within the paragraph. As a result, there may be times when the breakpoint intercept does not occur, or when the wrong sequence of statements appears to be executed while single-stepping. There may also be times when the debugger appears to highlight the wrong statement at a breakpoint intercept.

These unexpected displays do not indicate that a program is being executed incorrectly. They indicate that the debugger sometimes cannot accurately identify which object code corresponds to which source statement, or which statement is contained within which paragraph.

CA InterTest for CICS uses the information in the compiler-generated procedure map or offset report to establish the program offset for each statement and label in the program. During execution, the debugger recognizes the start of the new statement or label by matching the program offset of the currently executing instruction with the PROTSYM information obtained from the compiler listing. Therefore, the accuracy with which the debugger represents a breakpoint or other intercept is only as good as the information in the compiler listing.

Inaccuracies may include, but will not be limited to:

• Incorrect execution when using GO line-number.
• Failure to stop at a breakpoint at a paragraph label or statement.
• Unexpected or out-of-sequence highlighting of statements when single-stepping.

Additionally, application abends may result from the use of the GO line-number command because the optimized object code may have register requirements that do not support changes to the flow of control. These commands should be avoided when debugging an optimized program.

For the best debugging results, avoid using optimization whenever possible in your testing environment. Production applications may be compiled with optimization, and debugging these applications as they exist without recompiling is supported. However, you may experience some of the inaccuracies listed previously under these circumstances.