Using IBM Application Development Tools for z/OS and OS/390

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

default.

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

debugger

– 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&tcpip_address%port:*

Where:

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

debugger.

For the purposes of this example we are using the IBM Distributed Debugger watching

port 8000 on a machine at TCP/IP address 9.30.62.149. So the TSO command to call the

C++ IVP program we compiled above would be:

call ‘redbk1.dev.load(cppivp)’ ‘test(,,,VADTCPIP&9.30.62.149%8000:*) /’

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