Three Little Words That Simplify Debugging
March 7, 2007 Susan Gantner
|
I had struggled with using the debugger in WDSc for a long time when I asked a friend that I knew to be an expert on the subject to help me understand how to use it. She told me that I only needed to know three little words–Service Entry Points–to make my debugging life easier. She was right! If you have not yet learned the joys of debugging with Service Entry Points, try it today. In the Remote Systems view (RSE), choose a program object. Right click on the object and select Debug (Service Entry) –> Set Service Entry Point. It can sometimes take several seconds for anything to happen, but eventually, you should see a confirmation message and the Service Entry Points view appears in the workbench. Your program name appears in the list of Service Entry Points. The default settings include *All modules in the program, *All procedures in the program and your User ID. See Figure 1 below.
Setting that Service Entry Point says that when this program is invoked by your user profile, the iSeries debugger within WDSC will ask you if you want to debug it. If you say yes (and/or if you have specified that there is no need to ask permission) the following will happen:
Go to another job (e.g., an emulation session) and call the program and see this for yourself. It may take a while for the debug session to start up but when it does, you are ready to add any breakpoints you may need, set up fields you want to monitor values of as you are stepping through the program, issue a “Run to location” from a specific statement in the program or any of the other actions you may do within a WDSC debug session normally. I think that’s a pretty easy way to start a debug session. The best part is that it doesn’t matter whether I want to run the program from an interactive session or submit it to batch. Even better, if this program were invoked in some “non-traditional” way, such as in a Web server job or a remote procedure call, I don’t need to be concerned about figuring out what job needs to be debugged (or “serviced”). I can simply wait for the program to be invoked by my user profile wherever that is and it will go into debug mode for me. Of course, you are not limited to debugging only programs that you personally call. You can right click on the Service Entry Point in the list and select “Modify” to change the user profile and/or to specify which module(s) and procedure(s) you want to debug. Notice that from the right click menu, you can also remove a Service Entry Point or temporarily disable it. You may also do these actions from the tool bar icons at the top left corner of the view, as shown in Figure 2 below. Another important option you can use here is to refresh the Service Entry Point. You will need to refresh any time the program is recompiled.
Sadly, nice as they are, Service Entry Points are not a panacea. There are some limitations. For some shops the biggest limitation may be that they only work for ILE language programs, i.e., RPGLE, CBLLE, etc. Another limitation, which may seem counter-intuitive, is that you cannot debug a program called from the RSE server job using a Service Entry Point. You cannot currently debug a program that is suspended due to an error–in other words, you cannot debug a program after it has already failed. And don’t forget that you must refresh a Service Entry Point from RSE after the program has been recompiled. You may want to check out the preferences related Service Entry Points. From the Windows pull down menu, expand Run/Debug, then select iSeries Debug. Here you will find the often important “Update production files” preference for all types of debugging and some specific preferences for Service Entry Points. Hopefully these three little words will help to make your debugging life easier. Happy debugging. Susan Gantner is one of the most respected System i gurus in the world and is one of the co-founders of System i Developer, an organization dedicated to RPG, DB2, and other relevant software technologies for the System i platform. Gantner, who has worked in IBM’s Rochester and Toronto labs, left IBM to focus on training OS/400 and i5/OS shops on the latest programming technologies. She is a regular speaker at COMMON and other user groups, too. You can contact her at susan@SystemiDeveloper.com.
|
