Chapter 17. Debug Tool and debugging C/C++ 367
13.Run the program. This time it stops at the call to printf for the first parameter as shown in
Figure 17-11.
Figure 17-11 Stopped before printf call
14.Continue debugging as you wish.
17.3 Using the remote debugger
The MFI debugger in single screen mode is most useful on programs that neither read from or
write to the terminal. When debugging programs that do I/O, or programs that run under
CICS, the remote debugger is a better choice. PC programmers also appreciate the familiar
look and feel of the remote debugger.
Like many PC debuggers, the remote debugger automatically remembers the last
breakpoints and monitors that you used when debugging the program and brings them back
in. So no preference file is required.
Here are the steps needed:
1. The first step is preparing code for the remote debugger.
2. The next step is bringing up the remote debugger. For a Windows PC running the
distributed debugger, this usually involves a command like:
C:\IBMDebug\bin\idebug.exe -qdaemon -quiport=8000
On some installations, there may be an icon set up to automatically do this command.
Once the command has executed, a pop-up box like the one in Figure 17-12 will appear.
368 Using IBM Application Development Tools for z/OS and OS/390
Figure 17-12 Distributed Debugger awaiting input
The port was defined by the -quiport=8000 parameter that was passed to idebug. If 8000
is in use by another application, you should specify another port address. The WebSphere
Studio Enterprise Developer Compiled Language debugger will use a different port by
3. Invoke the program on the mainframe. For this you will need to know:
Whether you are using the VisualAge Remote Debugger, the IBM Distributed
Debugger, or the WebSphere Studio Enterprise Developer Compiled language
What port they are using
The TCP/IP address of their workstation
When bringing up the remote debugger, the fourth parameter of the TEST runtime option
is built as follows
product_keyword Is VADTCPIP if the VisualAge Remote Debugger or the IBM
Distributed Debugger is in use, and TCPIP if the WebSphere
Studio Enterprise Developer is in use.
tcpip_address Is the TCP/IP address of the workstation that will be debugging the
program. A machine name should be able to be used but this may
require additional work configuring TCP/IP. We have found the
actual address to be quicker and more reliable.
port Is the port that was specified when bringing up the remote
For the purposes of this example we are using the IBM Distributed Debugger watching
port 8000 on a machine at TCP/IP address So the TSO command to call the
C++ IVP program we compiled above would be:
call ‘’ ‘test(,,,VADTCPIP&*) /’
Chapter 17. Debug Tool and debugging C/C++ 369
The Debugger panel will now look as shown in Figure 17-13.
Figure 17-13 Distributed Debugger
4. As with the MFI debugger, on entry to the debugger, one can only monitor variables that
are at global scope. Since there are no global scope variables in the C++ IVP we use the
step button in the upper left hand corner to step into main. Then we choose to monitor the
variable bio. To do this:
a. Select Monitors.
b. Select Monitor Expression (or press Shift F9).
c. Fill in the variable name.
370 Using IBM Application Development Tools for z/OS and OS/390
This will put bio in the monitor window with a small + beside it. Clicking on the + expands
out the content of bio as shown in Figure 17-14.
Figure 17-14 The monitor screen showing the initial bio values
Chapter 17. Debug Tool and debugging C/C++ 371
5. Alternatively, if we only wanted to monitor bio while we were in function main, we could
simply choose the Locals tab in the bottom left hand sub window, to view all current locals
as shown in Figure 17-15.
Figure 17-15 Looking at the local variables

Get Using IBM Application Development Tools for z/OS and OS/390 now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.