Rational Developer for System z, Version 7.6

Debugging programs in a production environment

Programs in a production environment have any of the following characteristics:

This section helps you determine how much of Debug Tool’s testing functions you want to continue using after you complete major testing of your application and move into the final tuning phase. Included are discussions of program size and performance considerations; the consequences of removing hooks, the statement table, and the symbol table; and using Debug Tool on optimized programs.

Refer to the following topics for more information related to the material discussed in this topic.

Fine-tuning your programs with Debug Tool

After initial testing, you might want to consider the following options available to improve performance and reduce size:

Removing hooks

One option for increasing the performance of your program is to compile with a minimum of hooks or with no hooks.

Independent studies show that performance degradation is negligible because of hook-overhead for PL/I programs. Also, in the event you need to request an attention interrupt, Debug Tool is not able to regain control without compiled-in hooks. In such a case you can request an interrupt three times. After the third time, Debug Tool is able to stop program execution and prompt you to enter QUIT or GO. If you enter QUIT, your Debug Tool session ends. If you enter GO, control is returned to your application.

Programs compiled with certain suboptions of the TEST compiler option have hooks inserted at compile time. However, if the Dynamic Debug facility is activated (which is the default) and the programs are compiled with certain compilers, the compiled-in hooks are replaced with run time hooks. This replacement is done to improve the performance of Debug Tool. Certain path hook functions are limited when you use the Dynamic Debug facility. To enable these functions, enter the SET DYNDEBUG OFF command, which deactivates the Dynamic Debug facility. See Debug Tool Reference and Messages for a description of these commands.

It is a good idea to examine the benefits of maintaining hooks in light of the performance overhead for that particular program.

Removing statement and symbol tables

If you are concerned about the size of your program, you can remove the symbol table, the statement table, or both, after the initial testing period. For C and PL/I programs, compiling with the option TEST(NOSYM) inhibits the creation of symbol tables.

Before you remove them, however, you should consider their advantages. The statement table allows you to display the execution history with statement numbers rather than offsets, and error messages identify statement numbers that are in error. The symbol table enables you to refer to variables and program control constants by name. Therefore, you need to look at the trade-offs between the size of your program and the benefits of having symbol and statement tables.

For programs that are compiled with the following compilers and with the SEPARATE suboption of the TEST compiler option, the symbol tables are saved in a separate debug file. This arrangement lets you to retain the symbol table information and have a smaller program:

For C and C++ programs compiled with the C/C++ compiler of z/OS, Version 1.6 or later, you can compile with the FORMAT(DWARF) suboption of the DEBUG compiler option to save debug information in a separate debug file. This produces a smaller program.

Debugging without hooks, statement tables, and symbol tables

Debug Tool can gain control at program initialization by using the PROMPT suboption of the TEST run-time option. Even when you have removed all hooks and the statement and symbol tables from a production program, Debug Tool receives control when a condition is raised in your program if you specify ALL or ERROR on the TEST run-time option, or when a __ctest(), CEETEST, or PLITEST is executed.

When Debug Tool receives control in this limited environment, it does not know what statement is in error (no statement table), nor can it locate variables (no symbol table). Thus, you must use addresses and interpret hexadecimal data values to examine variables. In this limited environment, you can:

If your program does not contain a statement or symbol table, you can use session variables to make the task of examining values of variables easier.

Even in this limited environment, HLL library routines are still available.

Programs that are compiled with the following combination of compilers and compiler options can have the best performance and smallest module size, while retaining full debugging capabilities:

Debugging optimized COBOL programs

Before debugging an optimized COBOL program, you must compile it with the correct compiler options. See Choosing TEST or NOTEST compiler suboptions for COBOL programs.

The following list describes the tasks you can do while debugging optimized COBOL programs:

The enhancements to the compilers help you create programs that can be debugged in the same way that you debug programs that are not optimized, with the following exceptions

The Source window does display the variables and statements that the optimizer removed, but you cannot use any Debug Tool commands on those variables or statements. For example, you cannot list the value of a variable removed by the optimizer.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)