Debugging RPG IV Programs: The Green-Screen Way
Learn the secrets to debugging in green screen.
Lately we’ve been asked a surprising number of questions about how to debug RPG IV programs, so we thought it was time to cover the topic. Three primary debuggers are available from IBM – one green screen, one stand-alone GUI debugger and one in the WDSC toolset. In this article, we’ll cover the use of the green-screen debugger. We hope even those of you who already knew about the green-screen source view debugger pick up on a few often-missed features.
Perhaps it shouldn’t surprise us that many people don’t seem to even know that a source view debugger similar to the Start Interactive Source Debugger (STRISDB) used with RPG/400 is available for RPG IV programs. After all, the STRISDB command doesn’t work on RPGLE programs and the Start Debug (STRDBG) command doesn’t do anything terribly useful if you compile your programs using the system-shipped defaults.
Debug View Parameters
If you’re one of those folks who don’t realize you have a source view debugger for your ILE language programs, here’s the secret: the Debug View (DBGVIEW) parameter on the compile commands. The shipped default for this command (for some mysterious reason) is *Stmt, which means you can only set breakpoints the old fashioned way, i.e., without the benefit of source view.
The more productive way to debug ILE language programs is to use one of the other Debug View options. The most commonly used are *Source, *List and *All. *Source lets you use the source code from the member during a debug session. The issue you can run into with *Source is that the source member may have been changed since the program was compiled, making the debug session, at best, very confusing. Or the source may not even be available on the system where you want to debug the program. *List takes care of that issue by keeping a copy of the source in a compile listing format – with the compiled program object. This copy is complete with expanded file definitions and /Copy source. Don’t be misled into thinking that *Source stores a copy of the source with the program object – it doesn’t. We typically choose the *All option, which includes both the source view and the listing view. That way we always know we have a valid version of the source available for debug. After all, when debugging, we can use all the help we can get! The debug view parameter is one of the most frequently changed command defaults in most shops we see.
STRDBG
Assuming you’ve compiled the program with the source and/or listing view options, when you issue the STRDBG command on that program, the source will appear. You can then set breakpoints prior to activating the program if you wish. Once the program is running you can view and change the values of variables, step through the source, etc. If you’ve used STRISDB in the past, you’ll find many of the same options available to you, such as the capability to add breakpoints, step through the code one line at a time, and display and change values of variables in the program. Sometimes the way you do these is different. For example, in the STRDBG debugger you can display the value of a variable with F11 as you might expect, but to change its value, you use the EVAL command on the debug command line. You can see a value in hex format by placing “:x” after the variable name on the EVAL command.
Another significant difference is that by default the STRISDB command automatically called the program for you and paused at the beginning for you to add breakpoints or step into the code. The STRDBG debugger shows you the source for adding breakpoints but you must still call the program manually, typically by using F21 to bring up a system command line.
The Step function is available using either F10 to step only within the code in a single program or procedure, or by using F22 (conveniently Shift F10) to step into code on a call to another program or procedure. This Step Into feature is one that’s escaped many experienced users of the ILE debugger, who mistakenly think they must first set breakpoints in any called programs or procedures.
Another part of the STRDBG debugger that many people haven’t noticed is the capability to redisplay the source view debug screen in case you left it for some reason and want to go back to set another breakpoint or do some stepping through the code. While your job is still in debug mode, you can issue the Display Module Source (DSPMODSRC) command to get back to the source view debug screen.
If you want to add a program or service program to the debug session, you may either simply step into the program or procedure by using F22, or add a program or service program from the Work With Module List screen. You can get to this screen via F14 on the source view debug screen. From there, you may also display the source for another module or program so you can set breakpoints in the code without needing to step into the code.
While you’re looking at the source view debug screen, you may switch to the listing view version of the program by using F15 to “Select View”, assuming you’ve compiled with DBGVIEW(*All).
You’ll discover that a couple of features you may have used with STRISDB are missing. For example, the Run to Location function key isn’t there. Also the capability to watch the value of a set of variables while stepping through the code isn’t there – at least not in the same form.
There’s a Watch command and function keys to interact with it, but it works very differently from the other watch function. The Watch in STRDBG sets a watch breakpoint, which means you won’t see the values of the variables on the screen as you step through. However, whenever the value of a watched variable changes, the program will stop and a message informs you. You may then use F11 to view the current value of the changed field.
Both the capability to view the values of a set of variables directly on the screen while debugging the program and to Run to Location are available in the WDSC debugger. The WDCS debugger is our favorite and we’ll cover in a later issue of EXTRA.
Service Entry Points
Another feature that’s much nicer in the WDSC debugger is Service Entry Points (SEPs), which was added to i5/OS in V5R2 and is available for ILE language programs. While you can use these from the green screen, the interface is cumbersome and clumsy. A SEP is most useful when debugging either batch jobs or – even more so – server-type programs, such as Web programs. The problem with debugging these types of jobs is that you must first find the job before you can begin servicing it. Especially in the case of server jobs, the job to be serviced is often difficult to determine. SEPs help with that.
While the WDSC debugger has a much simpler way of doing this, we’ll briefly cover the way to use SEPs from a green screen. First, STRDBG on the program that will run in the server or batch job. Then find a statement number where you want to place a breakpoint to get control of the job for debugging. From the command line on the source debug screen, issue the debug command:
sbreak <STATEMENT number> user <USER name profile>.The user parameter isn’t necessary if the user profile used in the job to be debugged is your own (i.e., the user of the job you’re using for the STRDBG command). Then press F12 (resume) to release the debugger. Next do whatever’s necessary to start the program running in the batch or server job. When the program in that job reaches the statement number you entered in the sbreak command, your job will receive a message that a SEP has stopped at the statement number specified. The details of the job, including job number, user name and job name, will appear in this message.
Now comes the weird part – your next step is to go to a second emulation session (a separate interactive job) so you can enter two commands:
- Start Service Job (STRSRVJOB) for the job specified in the message.
- STRDBG on the program you were just debugging in the other job.
Once you’re in debug mode in the second job, set any breakpoints you want in that program and debug the program using this second emulation session as you would have if this were an interactive program. At this point, you may end the debug session in the earlier interactive job that you started for the purpose of setting the SEP.
As we said, it’s cumbersome and clumsy but if you need to debug those types of jobs, you can’t beat the functionality. However, it’s much easier to use with WDSC, but then you probably expected us to say that!
Handy and Helpful
We haven’t covered all of the features of the ILE language debugger, but you can get a great deal more information about the debug commands and facilities by pressing F1 from the source view debug screen. A lot of practical and useful help is there – more so than behind the F1 key on many other operating-system functions.
We hope this has helped some of you get a handle on debugging your programs. Until we get to the point where we can all write bug-free programs, debuggers sure come in handy!