IBMR Compiled Language Debugger 7.5 - Release Notes

Daemon port preference changes

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.

Working with the Engine Path in the "Edit Source Lookup Path" dialog

Adding an engine path updates the default path used by the debug engine.

To reset back to the default engine path:
  1. Add an empty engine path entry.
  2. Remove the empty entry.

New Default Editor support

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.

Important considerations when using the default editor support:
  • This support can be enabled/disabled using the preference:

    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.

  • The default editor for a language is defined in the preference:

    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.

  • Rational Developer for System z version 7.5 supports the following default editors:
    • System z LPEX Editor
    • Remote C/C++ Editor
  • When the source is obtained from the debug engine, the entire source is copied from the debug engine to a temporary file in the user's workspace. The temporary file is opened using the default editor in read-only mode. When the debug session finishes the temporary file is deleted.
  • If the source is local, either in a workspace project or the local file system, the default editor will load the local file in read-only mode. If the local file can be opened for edit an action may be available in the pop-up menu of the editor to allow the file to be modified. If source lines are added, removed or modified the debugger may not highlight the correct line when stepping or stopping on a breakpoint.
  • The language sensitive features of the default editor will be available including the outline view if supported by the editor.

Debug console content assist for Debug Tool commands

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.

Breakpoints support running Debug Tool 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.

Batch programs

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.

CICS remote debugging

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.

The debugger provides two interfaces for inserting the debug code into a CICS program during the Link step:
  • EQADCCXT - lets you dynamically change the destination of the debugger listing to a different workstation.
  • CEEUOPT - z/OSR inserts a static IP address and port number in the CICS program.
The following is an example of how the EQADCCXT interface was link edited into the CICS programs:
  • INCLUDE SYSLIB(EQADCCXT)
  • INCLUDE SYSLIB(DFHELII)
  • INCLUDE SYSLIB(DSNCLI)

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.

Debugging source files with duplicate names

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.

Project name longer than 80 characters causes problem in local debug

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.

Debugging a COBOL program with an XML PARSE statement

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.

Change in ADATA format produced by HLASM

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.