We have a web application written in RPG. We have written RPG programs that construct the HTML, the finished pages get sent to the browser, and when the user performs an action, page variables are sent back to the server (the IBM i). There is a background job running in batch that processes these requests. If this background job is busy when another request arrives, a new background job is spawned. If there is a lot of activity, it's not uncommon for a few background jobs to be running at the same time, each serving its own requests.
This complicates the task of debugging the RPG programs. We know what program to debug, but we don't know what background job to start servicing.
Service entry points solve this problem. With a service entry point, you can debug the RPG program, add a breakpoint and then whichever background job serves the request, the program will break at the breakpoint. The only problem is, you have to specify a user on the breakpoint. Fortunately for us, all the background jobs run under the same user, so we know it.
Adding A Service Entry Point
STRDBG on the program as you would normally. To add a breakpoint, use this syntax:
sbreak 718 user httpuser
sbreak is the command to add a breakpoint, 718 is the line number, and httpuser is the user (in our case) that will run the program (the current user profile of the background job). When the program breaks, you will see a program message; press F1 on the message to get the background job to STRSRVJOB on. Do the usual STRSRVJOB followed by STRDBG and hey presto, you are now debugging the program.
But this is green on black. You can much more easily debug using RDi - and that includes using service entry points.