This section describes some problems you might encounter while you try to debug complex applications and some possible solutions.
Debug Tool obtains information about programs in memory by using binder APIs. The binder APIs must access information stored in the data set containing the load module or program object. In most cases, z/OS can provide Debug Tool the data set name from which the program was loaded so Debug Tool can pass it to the binder APIs. However, z/OS does not have this information for programs loaded from LLA.
When Debug Tool attempts to debug a program loaded from LLA, Debug Tool does the following steps:
The following restrictions apply:
Debug Tool assumes that load module and compile unit names that begin with specific prefixes are system components. For example, EQAxxxxx is a Debug Tool module, CEExxxxx is a Language Environment module, and IGZxxxxx is a COBOL module.
Debug Tool does not try to debug load modules or compile units that have these prefixes for the following reasons:
If you have named a user load module or compile unit with a prefix that conflicts with one of these system prefixes, you can use the NAMES INCLUDE command and the instructions described in this section to debug this load module or compile unit.
You can display a list of prefixes that Debug Tool recognizes as system prefixes by using the following commands:
NAMES DISPLAY ALL EXCLUDED LOADMODS; NAMES DISPLAY ALL EXCLUDED CUS;
These commands display a list of names currently excluded at your request (by using the NAMES EXCLUDE command), followed by a section displaying a list of names excluded by Debug Tool.
Refer to the following topics for more information related to the material discussed in this topic.
If the name of your program begins with one of the prefixes excluded by Debug Tool, use the NAMES INCLUDE command to indicate to Debug Tool that your program is a user load module or compile unit, not a system program.
Refer to the following topics for more information related to the material discussed in this topic.
Some programs contain load modules or compile units that have no executable code. These modules are known as data-only modules. These modules are prevalent in assembler programs. In some situations, Debug Tool might not recognize that these modules contain no executable instructions and attempt to set a breakpoint, which means overlaying the contents of these modules.
In these situations, you can use the NAMES EXCLUDE command to indicate to Debug Tool that these are data-only modules that contain no executable code. Debug Tool will not attempt to set breakpoints in these data-only modules. If the NAMES EXCLUDE command is used to exclude a module that contains executable instructions, the module might still appear in Debug Tool and Debug Tool might still attempt to set breakpoints in the modules.
Refer to the following topics for more information related to the material discussed in this topic.
Some very large applications can contain a large number of load modules or compile units that you do not need to debug. In some cases, the creation and manipulation of debug data for these load modules or compile units can consume a significant amount of memory, CPU time, and other resources.
You can use the NAMES EXCLUDE command to indicate to Debug Tool that it does not need to maintain debug data for these modules. When you use the NAMES EXCLUDE command to exclude executable modules, there are situations where Debug Tool requires debug data for the excluded modules. The following list, while not comprehensive, describes some of the possible situations:
Also, when you enter a deferred AT ENTRY command, Debug Tool generates an implicit NAMES INCLUDE command for the load module and compile unit that is the target of the deferred AT ENTRY. If these names appear later in the program, Debug Tool will not exclude them even if you specified them in a previous NAMES EXCLUDE command.
In all of the above situations, Debug Tool loads debug data as required and these modules might become known to Debug Tool.
Refer to the following topics for more information related to the material discussed in this topic.
Use the NAMES DISPLAY command to display the current settings of the NAMES command.
Refer to the following topics for more information related to the material discussed in this topic.
You cannot use the NAMES command on load modules or compile units that are already known to Debug Tool; therefore, you cannot use the NAMES command to indicate to Debug Tool that you want to include or exclude the initial load module or the compile units contained in the initial load module. If you want to do this, you must code control statements into the EQAOPTS Debug Tool customization module with the equivalent NAMES command.
EQAOPTS enables you to customize specific Debug Tool functions. See Debug Tool Customization Guide for a complete description of EQAOPTS. You generate EQAOPTS by invoking the EQAXOPT assembler macro. Code the EQAXOPT assembler macro to process a NAMES command in the following format:
EQAXOPT NAMES,positional_parameter_2,positional_paremeter_3,positional_parameter_4
In this macro, the second, third, and fourth positional parameters are coded like the fields in the corresponding NAMES command. The following table describes how the Debug Tool command is coded into the equivalent EQAXOPT macro:
| Debug Tool command | EQAXOPT macro invocation |
|---|---|
| NAMES EXCLUDE CU "ABC1*"; | EQAXOPT NAMES,EXCLUDE,CU,ABC1* |
You can include as many invocations of the EQAXOPT macro with the NAMES option as you need in a single EQAOPTS.
Refer to the following topics for more information related to the material discussed in this topic.