Midrange Programmer

Have you ever watched with envy as your fellow Java or Visual Basic programmers navigate around in their cool source editors while you putter along in SEU? Who hasn't? Then along came CODE/400, and you were able to code right along with those young whippersnappers, without GUI envy. Then it came time to debug your code, and you had to switch to an iSeries green screen, while your counterparts debugged right from their cool editors. Well, have no fear, because the iSeries Distributed Debugger is here! Actually, it's been around for a while, but come on in and learn a little about it.

The iSeries Distributed Debugger is part of the WebSphere Development Studio client (WDSc). I am not going to cover WDSc or CODE/400 in this article; instead, I am going to pretend (I don't like to assume) that you have some knowledge of these tools, and that that's why you are here now. If you would like more information on WDSc and CODE/400, please checkout the Midrange Programmer index for the numerous articles we've written on those subjects.

Let's cover the basics, so you can get started. I am going to cover the most widely used form of debugging, and that is interactive debugging. You can start the debugger even without being in the WDSc application, by clicking the Microsoft Windows Start button, selecting Programs, IBM WebSphere Development Studio Client for iSeries, then IBM Distributed Debugger. You'll then see a window that allows you, for instance, to enter a bunch of information, including a job to debug, a program to add to debug, whether you want to debug Java. In later articles, I will cover those features, as well as other, more advanced types of debugging. For now, let's pretend you are in CODE/400 working on a source member. You've coded and compiled this member, and now you want to debug it. From your CODE/400 menu, select Action, then Debug. You will then see a menu that allows you to select whether you want to debug an interactive job, a non-interactive job, a currently running job, or a Web application. For now, we are just going to worry about interactive jobs, so select that option. The other way you can start an interactive debug session is to click the icon that looks like a beetle on the CODE/400 menu toolbar. In either case, you will be prompted to select the iSeries server to use. Select your server, which will probably be represented as OS/400 because it is the current server from where you uploaded the RPG code that you are debugging. Click OK.

The next window you'll see is the Call Program window. This allows you to select the program you want to call and fill in the necessary parameters. The program and library of the source member you were editing should default in the appropriate text boxes, and you can change them if you like. From there you can add or remove parameters and click OK to run this program.

A few things will happen next. First, a Java application that looks much like a DOS window will start. Then the IBM Distributed Debugger window will open, which will include a progress bar stating that the program you called is attempting to start. Last, you will be presented with a prompt to sign on to the iSeries. Type your user ID and password, and press the Enter key. You're debugging, right? Wrong, unless, of course, your iSeries was already properly set up or you already knew the necessary steps to take. The rest of you will see a debug message in the distributed debugger window stating that the debug server has not yet been started. It even tells you the command to use, Start Debug Server (STRDBGSVR). Once you enter that command from an iSeries command line, you're ready to rock and roll, right? Wrong. Before you go back and try to debug your application again, there is something else you will need to do. That is to start the code server using the STRCODE command. This command will not only allow you to debug your application, but will also allow you to enter iSeries commands from the CODE/400 command shell (F9 from your source member). So before you go back to your source member, make sure to enter the STRCODE command on an iSeries command line. Now you're ready to debug.

Click the little bug again, select the server, and sign on to your iSeries when the prompt asks you to do so. This time, if you've entered the appropriate commands on the iSeries, your debug session will start and will look a lot like the sample IBM Distributed Debugger window. The IBM Distributed Debugger window will display your source code on the right-hand side of the window, and the left side will be broken into two panes, one above the other. The top left pane will consist of tabs that allow you to look at stack data, the programs that are being debugged, and a list of the breakpoints. The lower left pane will consist of tabs that allow you to look at any monitors you've turned on and any local variables that reside in the program.

From here, there are many ways you can go. The first thing I noticed when using this debugger is that there is no function key 11 to check the contents of a variable. But there is even a better way to view the contents of a variable without setting up monitors. To do that, click Source in the debugger menu at the top of the window and select Allow Tool Tip Evaluation. Now, when you place your mouse over a variable name inside the source code pane, the value of that variable will be displayed in a little yellow window above that variable name. Cool, huh?

From here, you can do all the things you could do in the green-screen version of the debugger. Check out the menu at the top of the debugger window, and see how you can set and remove breakpoints; navigate through your program using the various step-through, step-over, run-to, terminate, and start-over options; look at the numerous source member options, and play with the various stack and monitor features.

Another common task I do in debug is to set monitors. To do this, click the Monitor menu option, at the top of the debug window, and select monitor expression. You'll be presented with a window that allows you to key in a monitor expression and select how you want to monitor that expression--a program or storage monitor. Key in a field name from your source member, and click the program monitor radio button, then click OK. Now you should see that field listed in the lower left windowpane when the Monitors tab is selected. As you move through your source member, you will be able to monitor the contents of that field. Right-click any monitor expression in that window, and you will have the option to edit that field. So if you want to test what would happen if a variable contained a specific value, you can easily edit that variable in the Monitor pane.

I have only touched on some of the features of the IBM Distributed Debugger. There is much more to learn, not only inside the interactive debugger, but the overall features as well. Play around with what I've showed you, and discover your own favorite ways to accomplish debugging tasks. Best of all, you can debug with your head held high, knowing that you don't need no stinking green screen.