IBM i > DEVELOPER > RPG

Debugging RPG IV Programs - The WDSC Way

IBM Systems Magazine, Business Systems edition Technical Editors Susan Gantner and Jon Paris share the second installment of their RPG debugging tips with a focus on WDSC. This method is Jon and Susan’s favorite way to debug, but it wasn’t always that way.


 

Last month, we covered using the green-screen Integrated Language Environment (ILE) debugger (www.ibmsystemsmag.com/i5/
enewsletterexclusive/18805p1.aspx
). This month, we’re going to look at our favorite debugger--the one built into WebSphere Development Studio Client (WDSC).

Since we use WDSC--or more specifically Remote Systems Explorer (RSE), its subset for RPG/COBOL/CL development--for editing our code, it makes sense to use it for debugging the code as well. However, for a long time, we didn’t use the debugger built into RSE because it was too cumbersome and had some design problems that often made it impossible to use in our firewalled network environment. Fortunately, some significant changes have been made in recent releases that solve these problems. So if some of you tried using the WDSC debugger a few years ago and, like us, gave up in frustration, give it another try with some of the pointers we’ll include here.

Service Entry Points

The most notable change to the ease of use is the support for service entry points (SEPs). We covered the use of SEPs from the green-screen environment in the last article and the interface in that case was cumbersome and non-intuitive. The WDSC debugger’s interface to SEPs is just the opposite--simple and straightforward, especially when compared to using the older style of WDSC debugging. It’s virtually the only way we ever attempt to debug programs using WDSC. SEPs have some limitations--specifically, that they only work with ILE language programs (i.e., the language type must end in LE, such as RPGLE) and the programs must have been compiled since V5R2, when the system support for SEPs was added.

Creating a SEP for a program essentially starts a monitor on the system to detect when a specific program is invoked anywhere on the system, optionally by a specified user profile. When it detects that situation, it starts servicing the job and fires up the WDSC debug perspective against that program. It makes it incredibly simple to connect WDSC to any job running on the host, so it becomes as easy to debug a batch or Web program as it is to debug an interactive green-screen one. The basic process works like this:

  • Set or create a SEP in WDSC for the program to be debugged, typically specifying your own user profile. More on how to do this is coming up.
  • Then start the program in another job (i.e., not your RSE server job). This could be as simple as calling the program from a command line in an emulation session, or you could submit a batch job or a CGI request via a browser.
  • The debug perspective in WDSC will begin on its own (or get focus if it was already started), the program’s source will be loaded and, by default at least, program execution will be stopped at a breakpoint at the beginning of the logic to let you add additional breakpoints, steps or other debug actions you need to take.

Now let's take a brief look at the details.

To start a SEP in WDSC, right-click on the *PGM object in your RSE view, and choose Debug (Service Entry)… and then Set Service Entry Point. If you prefer, you may also start a SEP from the source member for the program in the RSE view, in which case you’ll be prompted for the name of the program object or service-program object where the compiled code can be found. In either case, an entry should appear in a view called iSeries Service Entry Points in your workbench that looks something like Figure 1.

If no one’s used the WDSC debugger recently on your host system, you may get a message indicating the debug server must be started. In that case, right-click on iSeries Objects in your RSE view and select Remote Servers>Debug>Start. Then retry your SEP for your program.

After you see the SEP in the view as depicted in Figure 1, simply go to another job, such as an emulation session, and invoke the program. Your WDSC workbench should morph itself into the debug perspective and prepare a debug session on that program. Be patient--it’ll take a few moments, especially if you haven’t used it before. Wait until it’s finished the start-up process and is waiting for your action. Of course, you won’t see any source for debugging if you haven’t compiled the program with either Source, List or All for the debug view, as we covered last month.

Sometimes when you go into debug mode you’ll see a message about updating production data. This is exactly the same type of message that you’d get in a green-screen debug session if your program opens files for update and you’re debugging using files located in a library that isn’t designated as a test library (i.e., the Update production files option on the Start Debug (STRDBG) command. In the case of WDSC, to set the Update production files option, go to the pulldown menu, select “Preferences…,” then expand “Run/Debug,” click on “iSeries Debug” and tick the box next to “Update production files.” This setting will remain in place for future debugging sessions in your workbench.

By now, you should be in debug mode for the program. It may seem somewhat complicated reading this, but it’s really very simple once you’ve done it, because the debug server is now started on your host system and your debug preferences are set.

We don’t have the space here to go into detail on actually using the debugger. It should be fairly easy to navigate on your own, but here are a few highlights.

 

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters