Rational Developer for System z, Version 7.6

Appendix A. Data sets used by Debug Tool

Debug Tool uses the following data sets:

C and C++ source
This data set is used as input to the compiler, and must be kept in a permanent PDS member, sequential file, or HFS file. The data set must be a single file, not a concatenation of files. Debug Tool uses the data set to show you the program as it is executing.

The C and C++ compilers store the name of the source data set inside the load module. Debug Tool uses this data set name to access the source.

This data set might not be the original source; for example, the program might have been preprocessed by the CICS® translator. If you use a preprocessor, you must keep the data set input to the compiler in a permanent data set for later use with Debug Tool.

As this data set might be read many times by Debug Tool, we recommend that you do one of the following:

If your source code is being managed by a library system that requires the SUBSYS=ssss parameter when the data set is allocated, you need a custom version of the EQAOPTS options module that specifies the SUBSYS=ssss allocation parameter. This support is not available when debugging a program under CICS. See the Debug Tool Customization Guide for details.

COBOL listing
This data set is produced by the compiler and must be kept in a permanent PDS member, sequential file, or HFS file. Debug Tool uses it to show you the program as it is executing.

The COBOL compiler stores the name of the listing data set inside the load module. Debug Tool uses this data set name to access the listing.

Debug Tool does not use the output that is created by the COBOL LIST compiler option.

COBOL programs that have been compiled with the SEPARATE suboption do not need to save the listing file. Instead, you must save the separate debug file SYSDEBUG.

The VS COBOL II compilers do not store the name of the listing data set. Debug Tool creates a name in the form userid.cuname.LIST and uses that name to find the listing.

Because this data set might be read many times by Debug Tool, we recommend that you do one of the following:

EQALANGX file
Debug Tool uses this data set to obtain debug information about assembler and non-Language Environment COBOL source files. It can be a permanent PDS member or sequential file. You must create it before you start Debug Tool. You can create it by using the EQALANGX program. Use the SYSADATA output from the High Level assembler or the listing from the IBM® OS/VS COBOL or IBM VS COBOL II compiler as input to the EQALANGX program.
PL/I source (Enterprise PL/I only)
This data set is used as input to the compiler, and must be kept in a permanent PDS member, sequential file, or HFS file. Debug Tool uses it to show you the program as it is executing.

The Enterprise PL/I compiler stores the name of the source data set inside the load module. Debug Tool uses this data set name to access the source.

This data set might not be the original source; for example, the program might have been preprocessed by the CICS translator. If you use a preprocessor, you must keep the data set input to the compiler in a permanent data set, for later use with Debug Tool.

Because this data set might be read many times by Debug Tool, we recommend that you do one of the following:

If your source code is being managed by a library system that requires the SUBSYS=ssss parameter when the data set is allocated, you need a custom version of the EQAOPTS options module that specifies the SUBSYS=ssss allocation parameter. This support is not available when debugging a program under CICS. See the Debug Tool Customization Guide for details.

PL/I listing (all other versions of PL/I compiler)
This data set is produced by the compiler and must be kept in a permanent file. Debug Tool uses it to show you the program as it is executing.

The PL/I compiler does not store the name of the listing data set. Debug Tool looks for the listing in a data set with the name in the form of userid.cuname.LIST.

Debug Tool does not use the output that is created by the PL/I compiler LIST option; performance improves if you specify NOLIST.

Because this data set might be read many times by Debug Tool, we recommend that you do one of the following:

Separate debug file
This data set is produced by the compiler and it stores information used by Debug Tool. To produce this file, you must compile your program with the following compiler options:

Save the file in any of the following formats:

The compiler stores the data set name of the separate debug file inside the load module. Debug Tool uses this data set name to access the debug information, unless you provide another data set name as described in Appendix B. How does Debug Tool locate source, listing, or separate debug files?.

Because this data set might be read many times by Debug Tool, do one of the following steps to improve efficiency:

Preferences file

This data set contains Debug Tool commands that customize your session. You can use it, for example, to change the default screen colors set by Debug Tool. It should be kept in a permanent PDS member or a sequential file.

The default DD name for the Debug Tool preferences file is INSPPREF.

Global preferences file

This data set is similar to the preferences file, but it is specified through the EQAOPTS options load module. See the Debug Tool Customization Guide for more information about the EQAOPTS options load module. If a global preferences file exists, the commands specified in it are run before commands found in the preferences file.

Commands file

This data set contains Debug Tool commands that control the debug session. You can use it, for example, to set breakpoints or set up monitors for common variables. It should be kept in a permanent PDS member or a sequential file.

If a preferences file is available, the commands in the commands file are run after the commands specified in the preferences file.

Log file

Debug Tool uses this file to record the progress of the debugging session. The results of the execution of commands are saved as comments. This allows you to use the log file as a commands file in subsequent debugging sessions. It should be kept in a permanent PDS member or a sequential file. As this data set is written to by Debug Tool, we recommend you use a sequential file to relieve any contentions for this file.

The DD name for the Debug Tool log file is INSPLOG.

Log files are not used in remote debug mode.

The record format needs to be either F, FB, V, or VB.

Save settings file
Debug Tool uses this file to save and restore, between Debug Tool sessions, the settings from the SET command. A sequential file with RECFM of VB and LRECL>=3204 must be used.

The default name for this data set is userid.DBGTOOL.SAVESETS. However, this default can be changed by using EQAOPTS. In non-interactive mode (MVS batch mode without using a VTAM® terminal), the DD name used to locate this file is INSPSAFE.

You can not save the setting information into the same file that you save breakpoint and monitor specifications information.

Save setting files are not used for remote debug sessions.

Automatic save and restore of the setting is not supported under CICS if the current user is not logged-in or is logged in under the default user ID. If you are running in CICS, the CICS region must have update authorization to the save settings file.

Save settings files are not supported automatically when debugging DB2® stored procedures or under IMS/DC.

Save breakpoints and monitor specifications file
Debug Tool uses this file to save and restore, between Debug Tool sessions, the breakpoints, monitor specifications, and LDD specifications. A PDSE or PDS data set with RECFM of VB and LRECL >= 3204 must be used. (We recommend you use a PDSE.)

The default name for this data set is userid.DBGTOOL.SAVEBPS. However, this default can be changed by using EQAOPTS. In non-interactive mode (MVS batch mode without using a VTAM terminal), the DD name used to locate this file is INSPBPM.

You can not save the breakpoint and monitor specifications information into the same file that you save setting information.

Save breakpoints and monitor specifications files are not used for remote debug sessions.

Automatic save and restore of the breakpoints and monitor specifications is not supported under CICS if the current user is not logged-in or is logged in under the default user ID. If you are running in CICS, the CICS region must have update authorization to the save breakpoints and monitor specifications file.

Save settings files are not supported automatically when debugging DB2 stored procedures or under IMS/DC.


Terms of use | Feedback

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