Developer > WebSphere

More WDSC Debugging Tips

Three more WDSC tips debugging tips

In my last WebSphere Development Studio Client (WDCS) tidbit (www.ibmsystemsmag.com/i5/november07/
developer/18319p1.aspx), I wrote about how to debug using service entry points (SEPs). In this tip, I’ll continue down the path of debugging tools, because when a problem comes up it’s good to know all of your options to fix it quickly.

More Ways to View Variables in Debug

When debugging, it’s obviously advantageous to know the value of a particular variable. Since I frequently work with XML, I usually need to view a lot of variable data at once. I’ve found the regular Monitors approach in WDSC to be buggy in some cases as it won't let me view more than 2,048 characters of a 65,535 variable. By default WDSC's Monitor displays 1,024 characters of data. To expand beyond that, you need to modify manually how the variable is added to the Monitor tab. Figure 1 shows how to do this by clicking on the green plus sign and then specifying an eval string similar to what you’d enter on the green-screen command line of Start Debug (STRDBG). In this case, I specified “gReqData:c 5000.” This says to show 5,000 characters of variable gReqData. Figure 2 shows some eval expressions you can enter via this method for other purposes.

As I said, WDSC will sometimes only display 2,048 characters, so my alternative to that approach is to use the Monitor Memory feature. This is very cool indeed as it allows scrolling through your program’s memory starting at the location of your variables pointer. To monitor a variables memory, simply highlight it, right-click and select Monitor Memory>EBCDIC (see Figure 3). You’ll then be presented with the Memory tab. The other incredibly useful feature of this is to view the memory in Hex, which lets you see non-displayable characters like carriage return and line feed.

Speeding up Debug Startup

It never fails—after a few months of use on a new PC, it’ll slow down. Often, I’m at a total loss of how to address the speed issue so I simply let it go. Taking this approach is fine for things you aren't touching every few minutes, but when it came to my debugging in WDSC I knew something had to be done. Starting up a debug session in WDSC was taking way too long. It would take 20 to 30 seconds just to load the source on the screen and have that beautiful aqua line waiting to be executed on the first line of code. I should note that I have a very powerful PC (4GB RAM, mirrored 400GB SATA HDs and 2 Quad CPU @ 2.66Ghz) so I should be getting breakneck speeds.

It turns out the slow startup was due to more than 100 break points that had accumulated since I began using WDSC's debugger exclusively. Every time I started a debug session, the internal debugger was doing some sort of resolution of each break point, causing me to eventually notice a significant slowdown. This problem can be fixed quickly by navigating to the Breakpoints tab in the Debug view and selecting the double gray X to clear all break points (see Figure 4).

Debug Last Run

Like the tip before this, it’s important to have the debugging process streamlined because in iterative development every 20 seconds of wasted time adds up. To make the repeated debugging of the same program faster, I save my debugs so they can be reused with the click of a button. Figure 5 shows you how to do this by right-clicking on a program in Remote Systems Explorer and selecting “Debug (Prompt)(J).” That will prompt you with the debug screen where you can enter a name for this session. I’d use the name of the program (PARSE3 in this case). The next time you debug, this named session will be in the debug history and you can simply re-execute it by clicking the bug icon in the menu bar.

I’ll share more tips in the months to come. Happy debugging!