Debugging Server Jobs In Green Screen

Revised: October 3, 2012

by Susan Gantner

A few years ago, I wrote a tip about my favorite way to debug programs using the Service Entry Point (SEP) feature of WDSC, which I have now replaced with RDP Rational Developer for Power Systems. If you're a WDSC or RDP user and have somehow missed out on using SEPs for debugging, take a look at my tip.

If you don't use WDSC or RDP, you probably didn't pay any attention to that tip. As it turns out, SEPs aren't just for the graphical toolset. You can use SEPs with the traditional STRDBG "green screen" debugger as well.

You may be wondering why you should care? STRDBG works just fine as is, right? For interactive jobs, yes. Even for batch jobs when you're in control of the submission and can hold the job or the queue to do a STRSRVJOB, it works. But most shops are finding they have many other types of jobs that don't fit into those categories. What about web server jobs, such as those servicing CGI requests or database server jobs servicing stored procedure calls, from other platforms or exit programs? There are often multiple jobs servicing those requests, so just finding which job to service can be a challenge.

What if you could just specify the program you wanted to debug and the system would notify you when that program started to run in any of the available server job, or any other kind of job, for that matter? That's what SEPs do for you. And you can use them from the STRDBG green screen debugger.

An SEP is a breakpoint that will cause the program to stop when it is run in any job anywhere on the system by a specific user profile when the breakpoint is encountered.

Here's how. First, begin your debug session using STRDBG as you normally would, specifying the program you want to debug and any other options you may need. As usual, the source for the program appears. Find the statement number of a statement in the program, preferably near the beginning. This is where the program will stop once the SEP is triggered, giving you the chance to step or set other breakpoints.

Add a Service Breakpoint on that statement. There is no function key for setting a Service Breakpoint, so to do this, go to the debug command line and use the sbreak command. For example:

sbreak 105

In addition to the statement number, you also have the option of putting a user profile name in.

sbreak 62 user QUSER

If you don't specify a user, it will assume your user profile. Once you have entered the sbreak command, press F12 to exit the module source view.

Next, do whatever action it takes to cause that program to run with the specified (or assumed) user profile. What should happen next is that a message comes back to the job where you started the debug session. The message will look something like this:

Service Entry Point has stopped at line 3 in program LIBNAME/PGMNAME

You may notice that the line number where the message says it stopped is not the same as the statement number you specified for the Service Breakpoint. Don't worry about it. This number is a different type of line number to your source statements.

Position on that message and press F1 to get the full details for the message. In the details, you will see something like this:

Recovery  . . . :   This program must be debugged from a servicing job. Do a
Start Service Job (STRSRVJOB JOB(961729/GANTNER/QPADEV0003)). Then do
Start Debug (STRDBG) on the spawned job from where the STRSRVJOB was done.
Set a local breakpoint at or after the Service Entry Point. Return to the
original job and press enter to release the spawned job.

Leave this message there for the moment; do not press Enter yet. This is an unusually helpful message. Note that you can actually copy and paste that STRSRVJOB command with the job parameter on a command line. One detail that may not be clear from the message is that you must run the STRSRVJOB and STRDBG commands from another job, not the one where the message is displayed (hence the reference to a "servicing job").

Start another emulation session and paste the STRSRVJOB command onto a command line. Then issue (another) STRDBG command for the program in that job. As before, this will cause the source to appear. This time, you'll see that the source shows that the program has stopped on the statement where you put the Service Breakpoint (sbreak) earlier.

Set an ordinary breakpoint, using F6 or the Break command, on either that same statement or a later one. Go back to the original job where you did the first STRDBG (it should still be stopped at the message) and press Enter to reply to the message. At that point, or any time later, you can ENDDBG on the job where the message was.

Now you're in a debug session in the second emulation job. You can set any other breakpoints you like or use Step or whatever else you want or need to do to debug the program. You may notice that if you use Step, it will momentarily jump back to the service breakpoint before stepping to the next line of code. It seems a little strange, but otherwise, the debug session works much like an ordinary interactive debug session, albeit perhaps a bit more sluggish.

Don't forget that after you ENDDBG, you should also ENDSRVJOB before going on with the rest of your day.

If the process seems a bit cumbersome, you're right. The debugger with RSE that I described in the earlier tip does a lot of these steps for you, significantly simplifying the process. Still, compared to what actions would be required to debug these server or batch jobs, it is a very useful tool if you're stuck using the green screen debugger.

There are a few limitations I should mention related to Service Entry Points. SEPs came in at V5R2, so only programs that have been compiled since V5R2 can take advantage of them. Furthermore, the program that you use to get control of the job (the one where you use the sbreak command) must be a source member type that ends in LE, e.g., RPGLE, CLLE, CBLLE, etc. You can still debug non-LE programs once the debug process begins, but you can't put a service breakpoint into a program unless it is an "LE" type program.

I won't be using this process much in the future myself, because I much prefer doing my debugging with the RSE tool in RDP, as I covered in my previous tip. But if you don't have that option, SEPs are a big help for debugging in these situations.

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

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot