z/OS® Debugger uses the following data sets:
The C and C++ compilers store the name of the source data set inside the load module. z/OS Debugger 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 z/OS Debugger.
If you manage your source code with a library system that requires you to specify the SUBSYS=ssss parameter when you allocate a data set, you or your site need to specify the EQAOPTS SUBSYS command, which provides the value for ssss. This support is not available when debugging a program under CICS. To learn how to specify EQAOPTS commands, see the topic "EQAOPTS commands" in the IBM z/OS Debugger Reference and Messages or the IBM z/OS Debugger Customization Guide.
The COBOL compiler stores the name of the listing data set inside the load module. z/OS Debugger uses this data set name to access the listing.
z/OS Debugger 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.
For Enterprise COBOL for z/OS Version 5 and Version 6 Release 1, program listings do not need to be saved. The debug data and the source code is saved in a NOLOAD segment in the program object.
For Enterprise COBOL for z/OS Version 6 Release 2, program listings do not need to be saved. The debug data and the source code are saved in a NOLOAD segment of the program object if you specified TEST or TEST(NOSEPARATE,SOURCE), and in a separate debug file if you specified TEST(SEPARATE,SOURCE).
The VS COBOL II compilers do not store the name of the listing data set. z/OS Debugger 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 z/OS Debugger, we recommend that you do one of the following:
The Enterprise PL/I compiler stores the name of the source data set inside the load module. z/OS Debugger 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 z/OS Debugger.
Because this data set might be read many times by z/OS Debugger, we recommend that you do one of the following:
If you manage your source code with a library system that requires you to specify the SUBSYS=ssss parameter when you allocate a data set, you or your site need to specify the EQAOPTS SUBSYS command, which provides the value for ssss. This support is not available when debugging a program under CICS. To learn how to specify EQAOPTS commands, see the topic "EQAOPTS commands" in the IBM z/OS Debugger Reference and Messages or the IBM z/OS Debugger Customization Guide.
The PL/I compiler does not store the name of the listing data set. z/OS Debugger looks for the listing in a data set with the name in the form of userid.cuname.LIST.
z/OS Debugger 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 z/OS Debugger, we recommend that you do one of the following:
The compiler stores the data set name of the separate debug file inside the load module. z/OS Debugger uses this data set name to access the debug information, unless you provide another data set name as described in How does z/OS Debugger locate source, listing, or separate debug files?.
Because this data set might be read many times by z/OS Debugger, do one of the following steps to improve efficiency:
To learn how to use these commands, see z/OS XL C/C++ User's Guide.
This data set contains z/OS Debugger commands that customize your session. You can use it, for example, to change the default screen colors set by z/OS Debugger. Store this file in a permanent PDS member or a sequential file.
You can specify a preferences file directly (for example, through the TEST runtime option) or through the EQAOPTS PREFERENCESDSN command. For instructions, see Creating a preferences file.
A CICS region must have read authorization to the preferences file.
This is a preferences file generally available to all users. It is specified through the EQAOPTS GPFDSN command. To learn how to specify EQAOPTS commands, see the topic "EQAOPTS commands" in the IBM z/OS Debugger Reference and Messages or the IBM z/OS Debugger Customization Guide. If a global preferences file exists, z/OS Debugger runs the commands in the global preferences file before commands found in the preferences file.
A CICS region must have read authorization to the global preferences file.
This data set contains z/OS Debugger commands that control the debug session. You can use it, for example, to set breakpoints or set up monitors for common variables. Store it in a permanent PDS member or a sequential file.
If you specify a preferences file, z/OS Debugger runs the commands in the commands file after the commands specified in the preferences file.
You can specify a commands file directly (for example, through the TEST runtime option) or through the EQAOPTS COMMANDSDSN command. If it is specified through the EQAOPTS COMANDSDSN command, it must be in a PDS or PDSE and the member name must match the name of the initial load module in the first enclave. For instructions on creating a commands files, see Creating a commands file.
A CICS region must have read authorization to the commands file.
The record format must be either F or FB and the logical record length must be 80.
A CICS region must have read authorization to the EQAOPTS file.
z/OS Debugger uses this file to record the progress of the debugging session. z/OS Debugger stores a copy of the commands you entered along with the results of the execution of commands. The results are stored as comments. This allows you to use the log file as a commands file in subsequent debugging sessions. Store the log file in a permanent PDS member or a sequential file. Because z/OS Debugger writes to this data set, store the log file as a sequential file to relieve any contention for this file.
z/OS Debugger does not use log files in remote debug mode.
You can specify a log file directly (for example, the INSPLOG DD or the SET LOG command) or through the EQAOPTS LOGDSN command. For instructions, see Creating the log file.
For DB2® stored procedures, to prevent multiple users from trying to use the same log, do not use the EQAOPTS LOGDSN command.
For CICS, review the special circumstances described in Restrictions when debugging under CICS.
The default name for this data set is userid.DBGTOOL.SAVESETS. However, you can change this default by using the EQAOPTS SAVESETDSN command. In non-interactive mode (MVS batch mode without using a full-screen terminal), the DD name used to locate this file is INSPSAFE.
You can not save the settings information in the same file that you save breakpoint and monitor specifications information.
Save settings files are not used for remote debug sessions.
Automatic save and restore of the settings 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.
You or your site can direct z/OS Debugger to create this file and enable saving and restoring settings through the EQAOPTS SAVESETDSNALLOC command. For instructions, see Saving and restoring settings, breakpoints, and monitor specifications.
The default name for this data set is userid.DBGTOOL.SAVEBPS. However, you can change this default by using EQAOPTS SAVEBPDSN command. In non-interactive mode (MVS batch mode without using a full-screen terminal), the DD name used to locate this file is INSPBPM.
You can not save the breakpoint and monitor specifications information in the same file that you save settings 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 breakpoints and monitor specifications files are not supported automatically when debugging DB2 stored procedures.
You or your site can direct z/OS Debugger to create this file and enable saving and restoring breakpoints and monitor specifications through the EQAOPTS SAVEBPDSNALLOC command. For instructions, see Saving and restoring settings, breakpoints, and monitor specifications.