The port used by the Debug Daemon is now saved in the workspace. Each workspace can now have a different debug daemon port.
The Change Port... action on the Debug Daemon will display the Debug Daemon preference page. The preference page permits changing the port and supports setting a new default port. The "Set as Default" button will save the port value as the new default and new workspaces will use the new default port.
Adding an engine path updates the default path used by the debug engine.
In previous releases of RationalR Developer for System zTM, the Compiled Language Debugger would use a specialized Debugger Editor to display the program's source or listing views. Rational Developer for System z now supports using the default editor when debugging COBOL or PL/I programs (either local or host). This support applies to programs that have a source view. All other views (Disassembly or Listing) continue to use the Debugger Editor.
Run/Debug -> Compiled Debug -> Always use Debugger Editor while debugging
When the preference is selected (checked) the internal Debugger Editor will be used. When the preference is not selected (unchecked) the debugger will open the default editor based on the language of the program being debugged.
General -> Editors -> File Associations
File extensions determine which editor will be used to display the source of a program being debugged. The debugger will assign a file extension to source retrieved from the debug engine that matches the programming language of the program.
Basic support for content assist has been added to the Debug Console View. Pressing Ctrl+Space in the Command Input field will list all of the supported Debug Tool commands. The list is based on the level of the connected Debug Tool. As characters are entered the list is filtered to show matching commands.
Newer versions of the Debug Tool engine will support running Debug Tool commands when a breakpoint is hit. When connected to a Debug Tool engine that supports commands on a breakpoint a new field will appear on the "Optional parameters" page of the breakpoint wizard. Debug Tool commands entered on the breakpoint will be executed when the breakpoint is hit.
Debugging a batch PL/I program does not work if the source is inline in the JCL. The debugger requires a source file.
When you perform Debug Application on a remote executable, this action starts a batch debugging session. Since the application is running in batch, you cannot provide program input at the TSO command prompt. To work around that, provide any necessary user input in the additional JCL field in the Runtime options property page of the project.
In addition to the DTCN transaction, with CICSR TX Series, the CADP transaction can be used to debug a remote transaction. Please see the Debug Tool Users Guide for more information.
If you decide to use the EQADCCXT interface, the debugger provides a CICS program called Debug Tool Control Panel to dynamically change your debug test environment. The debug session can be tested solely on the CICS region using the MFI protocol or redirected to a workstation, where Rational Developer is running, using the TCP protocol.
The Debug Tool Control Panel can be started by entering DTCN at the CICS terminal. When the Control Panel appears, simply enter TCP for the protocol, the port number on which the Rational Developer for System z debugger server program is listening on the workstation (usually port 8001) and the IP address of the workstation. Specify the transaction ID that maps to your program definition. Press PF4 to save and PF3 to exit. At this point, check Rational Developer for System z to make sure that the debugger server is listening at the correct port number. You can invoke the CICS program (via the transaction ID) and the Debug perspective should come into view in Rational Developer for zSeriesR on your workstation.
There is a known problem with the workstation distributed debugger that can cause it to debug the wrong source file. Given the same source file name in two Local Projects, the wrong application is debugged. Setting breakpoints in the source file in one will cause the debugger to stop in the other source file as if breakpoints were set in it. This is a known defect and will be fixed in a future release of the product. To work around the problem, keep only one source file with a given name in your workspace. To work around the breakpoint problem, continue pressing Run in the distributed debugger to skip over unwanted breakpoints.
Local debug of an executable residing in a project with a name longer than 80 characters may result in a "Communications failure" error in the debugger, ending your debug session.
When debugging a COBOL program with an XML PARSE statement, variables may not appear in the Variables view, and variables may not support being monitored. When you want to see all of the variables in the Variables view, click on the COBOL program in the stack that is the name of the COBOL program in the Debug window. For example, if you are debugging a COBOL program called XML1, in the stack you will see XML_XML1 and XML1. You need to click on XML1 and then click on the Variables tab.
When you want to monitor a variable, in the source window, click on the line with the PROGRAM-ID; then, in the Monitors window, add the data-item you want to monitor.
The format of the ADATA produced by the High Level Assembler (HLASM) has changed format from Version 1 Release 4 to Version 1 Release 5. The Debug Tool utility EQALANGX - needed for debugging symbolic assembler debugging - requires the ADATA Version 1 Release 4 format. HLASM ships an optional ADATA exit, ASMAXADR, that converts the ADATA file from Release 5 to Release 4 format. You must install and enable this exit for the Debug Tool symbolic HLASM debugging. If you do not convert the ADATA format to the Release 4 format, the EQALANGX utility will seemingly succeed and the failure will occur during the debug session.