Most AS/400 programmers would agree that writing new code is a far more interesting task than finding problems in existing programs. Figuring out problems in your own code is not too bad because you usually have a relatively clear idea about what is going on. It is a much more difficult task to fix bugs in someone else’s program. Without a good set of debugging tools, even very simple bugs may take days or weeks to find.

For years, AS/400 programmers have been using System Debugger and the Interactive Source Debugger (ISDB). Both tools are fairly powerful and provide solid debugging capabilities. Yet both have a green-screen interface. This may be sufficient for some debugging tasks, but it is not as elegant or effective as a GUI. Most of the current debugging tools on PC and UNIX provide point-and-click features because debugging is one of those tasks that truly benefits from a GUI. To further complicate matters, with Java becoming a major language on the AS/400, we may see a large number of workstation programmers developing client/server applications on the AS/400. More and more developers will no longer feel comfortable with the green-screen tools.

Foreseeing these difficulties, IBM has developed a number of client/server tools that give developers the full advantage of a GUI while still targeting the AS/400 platform. You may already be familiar with products like CODE/400 and VisualAge for RPG. Currently, both of these products are being marketed as an ADTS Client Server for AS/400 solution. The client part of these products runs on Windows 95 and Windows NT
4.0 platforms, while the server supports all RISC releases of OS/400 and V3R2. ADTS Client Server for AS/400 integrates a set of tools including a Live Parsing Extendable (LPEX) editor, program verifiers, an AS/400 graphical screen designer, and both the Cooperative Debugger and RPG workstation debugger. The ADTS product allows programmers to develop AS/400 applications from their PC desktops. One of the latest

client/server products released by IBM is VisualAge for Java. It incorporates a set of Java development tools for the AS/400, the workstation, and 390 platforms.

The Cooperative Debugger

The client/server tool that I will be describing in detail is the Cooperative Debugger. Following the footsteps of the AS/400 System Debugger, the Cooperative Debugger allows the debugging of applications written in most available languages, while bringing to the developer’s disposal the power of a GUI. This debugger supports Original Program Model (OPM) and ILE languages, including CL, RPG, COBOL, C, C++, and Java. Moreover, it allows the debugging of programs that consist of modules written in various languages. This will become more and more important as a large number of the legacy applications written in RPG or COBOL will be enhanced using Java or C++. It is no surprise that IBM packages Cooperative Debugger as a part of ADTS Client Server for AS/400 as well as the VisualAge for Java AS/400 feature.

What makes Cooperative Debugger attractive to AS/400 programmers? For those who come from a workstation background, the debugger offers the familiar look and feel of a workstation debugger. The GUI is very similar to that of the VisualAge family of debuggers. For green-screen developers, Cooperative Debugger gives an all-new point- and-click appearance while still preserving the feel of the AS/400 System Debugger. It makes debugging batch jobs easier than ever. As a matter of fact, the programmer does not even need to specify whether the debugged job runs interactively or in batch, or whether the program is OPM or ILE—the debugger takes care of all these details.

Another advantage of the GUI is that all the required screens of information can be displayed at the same time. There’s no need to press some function key or Enter to switch from a Source Code view to the Call Stack or Variable Monitor views. All windows are in front of the user, easily sizable to one’s liking, and kept in synch during program execution.

Debugger Windows

The name of the Debugger - Session Control (DSC) window says it all. Shown in Figure 1, it is the main window for the current debug session. It serves the purpose of the main control panel, where you can add new programs, service programs, modules, and classes to the debug environment. Also, the DSC window lists those modules, classes, procedures, and methods that constitute a program.

From this list, you can select the source to be displayed for an ILE module or C++ class. All these actions are initiated by clicking on the entries in the right portion of the DSC container.

This window roughly corresponds to the Add Module Source panel of the System Debugger. However, it offers a richer set of attributes than its green-screen counterpart. From the DSC, the user can do the following:

• Issue program execution commands such as Run and Restart
• Search for a particular procedure or current execution point
• Bring up stack and local variable monitors
• Display the Line and Watch Breakpoint dialogs From the DSC window, the user can tailor the global debugger settings, such as default data representations for various language groups, program profiles, monitor properties, and window presentation properties. The user can also terminate the debug session from the DSC window by pressing F3.

Each debug session can have only one control panel and hence only one DSC window. The Debug Source window (see Figure 2) is a different story. While the user debugs an AS/400 program, only one module can contain the current execution line. But

the user may choose to display the source for a few different modules simultaneously. So at any given time, more than one Debug Source window may be displayed.

This allows better navigation through the program. It is particularly convenient to display the source of the caller and the callee at the same time, even if both procedures belong to different modules. For most languages, Cooperative Debugger supports the *Text, *Listing, and *Statement views if the program was compiled with one of these three debug options. You use the View menu to switch between available views. The left margin of the Debug Source window, which contains line numbers, is called prefix area. The rest of the window contains actual source of your program. For visual convenience, all executable lines are colored in blue, while comments and other nonexecutable statements are shown in gray (these colors are not customizable).

The vast majority of debug actions can be performed from the Source window (for example: stepping, running, setting various kinds of breakpoints, displaying variables, and bringing up the Call Stack and Breakpoint List windows). There is usually a very intuitive (point-and-click) way of performing these operations. However, those familiar with the green-screen tools can take the alternative route of typing the appropriate debugging command in a corresponding entry field that resembles the System Debugger interface.

Step and Run Before Reaching the Breakpoint

Cooperative Debugger supports two stepping modes: step over and step debug. Both actions are accessible from the toolbar or the Run menu in the Debug Source window. The step debug action should be used when execution is stopped at the call to some routine that we would like to debug. In any other situation, step over is a preferable action. The corresponding accelerator keys are O and D. (In this case, accelerator keys are invoked by simply pressing a letter that corresponds to the action—O for step over and D for step debug.)

Run and Run to Location commands are also available from the Run menu (with corresponding accelerator keys R and L). The latter command could be accessed through a pop-up menu. The pop-up menu can be invoked by pressing the right mouse button in the prefix area of any executable line.

Breakpoints can be set by double-clicking in the prefix area of any executable line. Alternatively, you can use the Line Breakpoint dialog (see Figure 3) invoked from the Breakpoints menu. From this dialog, the user can set a conditional breakpoint by entering any valid Boolean expression in the Expression field. Once a breakpoint has been set, the prefix area of that line turns red (as shown in Figure 2).

Watches are set through the Watch Breakpoint dialog (see Figure 4), which is also invoked from the Breakpoints menu in the Source window. Using watches can be handy when you want to monitor changes for the same variable or variables as you step through the code. Watches can be set for any valid variable. If the content of a watched variable changes during the execution of your program, execution stops, and the user gets control and is notified about the variable being changed. Currently, watches are not supported for Java.

All line breakpoints and watches that are set successfully will show up in the Breakpoints List window (see Figure 5). From that window, the user can modify breakpoint properties and enablement. Cooperative Debugger currently supports line breakpoints and watches. However, there are plans to add advanced breakpoint features.

Displaying Variables

One of the major advantages of Cooperative Debugger over its green-screen counterparts is the availability of various monitors to display variables. There are four types of monitors: program monitors, private monitors, pop-up monitors, and local variable

monitors. Each one has certain advantages. However, two of the more commonly used ones are the program and local variable monitors.

Adding a variable to the program monitor is as easy as highlighting the appropriate variable in the Source window and double-clicking on it. Alternatively, the Monitor Expression dialog can be used to add a variable to a program, private, or pop-up monitor.

Bringing up a local variable monitor is a matter of choosing the Local Variables option from the Monitors menu in the Source window. This option is also available from the DSC window.

Just like the local variables monitor, the Call Stack window (see Figure 6) could be invoked from the Monitors menu in the Source window or from the DSC window. The Call Stack window contains an entry for every procedure or method that is on the stack at the current execution point. Double-clicking on the call stack entry brings up a source view of the corresponding routine. Each call stack entry contains complete qualification information, such as program, module name, procedure name, statement number, and call level number. This window becomes very handy while debugging deeply nested procedure calls.

It is the existence of the Program Monitor window (see Figure 7) that makes Cooperative Debugger such an invaluable tool. Variables can be added to the Program Monitor by double-clicking in the Source window or using a Monitor Expression dialog. Changing a variable’s value is just a matter of another double-click and typing a new value in the editable part of the window’s container. Data structures can be expanded by double- clicking on the data structure name. Displaying and changing array elements can also be done with ease.

In the Program Monitor window, the user has the capability of removing a particular expression, clearing the entire monitor, changing the expression’s representation, or toggling the expression’s enablement. Full expression qualification can be displayed, although I rarely find it useful.

The Breakpoints List window (see Figure 5) contains every line and watch breakpoint that is set for the current debug session. This is a very convenient place to tamper with breakpoint entries. Double-clicking on the breakpoint entry in the Breakpoints List window brings up the module source view where the breakpoint is set. From this window, the user can delete a particular breakpoint or even all breakpoints, toggle breakpoint enablement, and modify existing breakpoints.

Another handy feature offered by Cooperative Debugger is the availability of the program profile. Breakpoints and monitor information can be preserved from one debug session to another. Simply mark the Use program profile checkbox in the Startup dialog in order to take advantage of this feature.

Give It a Try

I had used the System Debugger for a few years before I came across Cooperative Debugger. After a year and a half of successful experience with this tool, I would definitely not go back to the green-screen. I believe that Cooperative Debugger has saved me many hours of typing and showed me the full power of a GUI. It certainly deserves a try from any developer who regularly debugs AS/400 programs.

Vadim Berestetsky would like to express special thanks to Inge Weiss for her contributions in assuring technical accuracy of this article as well as providing invaluable comments and suggestions.

Figure 1: Debugger-Session Control window

 Figure 2: Debug Source window

Figure 3: Line Breakpoint window

 Figure 4: Watch Breakpoint window

Figure 5: Breakpoints List window

 Figure 6: Call Stack window

Figure 7: Program Monitor window

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails