RDi Debug Without SEPs

I wrote a tip way back in 2007 about how easy it is to start a debug session using Service Entry Points (SEPs). Back then, the tool was still called WDSC, and at that time I mentioned that there were some occasions when SEPs wouldn’t work. So what can you do if you’re in one of those situations?

You can’t set an SEP on a program whose member type doesn’t end in LE. For example, with RPG or CLP programs. That’s not to say that you can’t debug non-LE programs when using SEPs–you simply can’t use one of those program types to start the debug session. Therefore, one solution may be to create a CLLE or RPGLE program that does nothing but call the non-ILE-type program. Set your SEP on the ILE program and then step into the one you need to debug. That won’t be practical in all situations, so read on for ways to debug without SEPs.

Another situation where SEPs don’t work is when the program is already running, perhaps in a never ending background job. For SEPs to work, the system needs to detect the program at its “entry point” so those kinds of jobs don’t work for SEPs. And every now and then, I have had an SEP just refuse to connect to the debugger for reasons I never figured out. It has happened very rarely, but it’s always good to know there’s another way to start a debug session.

What you need to do is to create and use a debug configuration. There are many types of debug configurations, but the one that I find most useful is a job configuration. That will allow you to point to a specific job that you want to debug. My preferred method for creating a job configuration is to use the RDi Jobs subsystem to find that job. But I’ll also describe another option.

Using Remote Systems Jobs

To use RDi’s Jobs subsystem, you first need to locate it in the Remote Systems view. You can find it below all your library/object filters and just above IFS Files and Spooled Files. You can see what it looks like in my Remote Systems view in Figure 1. Simply find the job you want to debug using one of the jobs filters. I typically use “My Active Jobs” when it’s a job using my user profile. When you find the job, right click on it and choose “Debug (Prompt) > IBM i Job”. In the resulting dialog box, fill in the name of the first program you want to debug. Typically the “Step into” box is checked, which means the program will stop on the first line of code to allow you to add any breakpoints you want or to step through the code.

Figure 1.

If needed, ensure the “Update production files” box is checked as well. You may want to note–and potentially change–the name of the debug configuration RDi is creating for you for reasons I’ll explain in a moment. It’s at the top of this dialog box and by default will be something like “My job.” Once you have made all the changes you need, then press “Apply” and “Debug”.

Next, you’ll be switched to the Debug perspective, where a message awaits: “Use Step or Resume to continue your debug session and start your application on the server.” After dismissing the message box with OK, do what it says. Assuming it’s an interactive program I’m debugging, I typically press the Step Into icon in the toolbar or press F5 and then call the program from my interactive job’s command line. At that point, the program’s source appears in the editor (if it wasn’t already there) and the debug session begins.

What if you get all the way through the program and want to call it in debug again? In an SEP debug session, you can simply call the program again to continue debugging it. But with configuration debug, you need to start another debug session for the same job/program combination by requesting to run the same configuration again. I use the debug icon in the toolbar to do this. It’s a fairly obvious picture of a green bug, which you can see in Figure 2. Clicking on the bug will re-run the last configuration that was run, but I usually prefer to verify that I’m getting the correct one. So I click on the menu arrow next to the bug and pick my debug configuration name from the list.

Figure 2.

Manually Creating The Configuration

If you don’t want to create your debug job configuration from the Jobs subsystem from Remote Systems, you can also create one manually. There is a “Debug configurations. . .” option that you can find by pressing on the arrow by the debug icon, or the same option can be accessed from the Run menu. When you take that option, you’ll see the very wide variety of types of debug configurations there are, including six whose names contain “IBM i”. Since all programs run in jobs, the generic “IBM i: Debug Job” option works for nearly all circumstances, so I use that one all the time.

I would particularly advise against using what may be the most tempting one–“IBM i: Debug Interactive Application”–because it will ask you to use the STRRSESVR (Start RSE Server) command to tie your interactive job to your RSE session. I’ve found that setup to be cumbersome and confusing to use, so I prefer to stick with Debug Job. The biggest issue with a job debug configuration can be finding and specifying the job to debug.

To help you find the job to debug, RDi has a helpful job browse feature. By default when creating a new debug job configuration, it contains *CURRENT for the job user and * for both the job name and number. Using the Browse button brings up a list of jobs for the specified user. Select the one you need and it fills the details into the configuration for you.

Debug Preferences

Regardless of how you start your debug session, you may first want to set some preferences. The most important one for most people is the “Update production files” preference. If you need to say Update(*Yes) with STRDBG, then you’ll want to know how to specify that as your default for debugging with RDi. As with all RDi preferences, you get to them using the last option from the Window menu. Keying “debug” into the filter box at the top of the left-hand panel makes it much easier to find the “IBM i Debug” option, which is where the “Update production files” checkbox can be found. That’s the only debug preference that I’ve found important to change but you may want to look around at other options, both on that page as well as other pages related to debugging, such as the “Debug Editors” page.

So now you know two ways you can start a debug session: either with an SEP or with a debug job configuration. If you’d like to see a brief demonstration of my favorite methods of starting a debug session, including most of the steps you’ve read here and using SEPs, check out my video on starting a debug session. From my last tip, you also know about different types of breakpoints and how to manage them. What else can you do in an RDi debug session? You can step through your code while monitoring your data values. So in my next tip, I’ll explore those options.

Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.

RELATED STORY

Three Little Words That Simplify Debugging