Guru: Graphical Debugging Through ACS
June 8, 2020 Ted Holt
ACS (IBM i Access Client Solutions) keeps getting better and better. I can’t stay up-to-date with the latest releases of all the software I use, but I do everything I can to keep up-to-date with ACS. One of the handiest of the relatively most recent releases is the ability to access IBM i Debugger through Run SQL Scripts. If you haven’t tried IBM i Debugger, you’re missing out.
IBM i Debugger (a.k.a. System Debugger) is part of the IBM Toolkit for Java. It’s graphical, and it makes the green-screen debugger (STRDBG) look like something built by cavemen. To show you how to access it through ACS, I debug a small interactive green-screen program.
I can’t reference the debugger from the main ACS menu. Instead, I have to start Run SQL Scripts and take the System Debugger link under the Run menu, as shown in Figure 1.
Figure 1: Start IBM i Debugger from Run SQL Scripts.
Once the debugger is open, I select the Start Debug option from the Debug menu to open the Start Debug dialog. (Please see Figure 2.)
Figure 2: Use the Start Debug dialog to set up to debug a program.
If the program to be debugged does not use a display file, you have two options. You can debug an existing job or you can let the debugger run your program as a batch job. Since my program uses a display file, I have to run in a 5250 session, which I specify as the existing job.
After filling in the appropriate information, I click on OK to proceed to the debugging screen. (Please see Figure 3.)
Figure 3: The system debugger screen.
The problem with this program is that it does not retrieve a customer name from the database. To add a breakpoint at the CHAIN operation, I click once to the left of the line number 5. The debugger places a red arrow where I clicked. Clicking on the arrow would remove the breakpoint.
I click the green arrowhead (“Resume”) just under the menu bar to continue. Then I switch to that job and call the program I want to debug. I enter the customer account number and press Enter in my 5250 session. The debugger stops at the breakpoint. (Please see Figure 4.)
Figure 4: The Locals tab displays values and allows them to be changed.
Notice the bottom left panel. The Locals tab interests me. It shows me the local variables for the main routine or current subprocedure. If I wish, I can double-click on a value to change it. I can also hover the mouse pointer over a variable to see its value in a pop-up.
I see the problem. The program uses the CUST field, which is defined in the database file, to read file YG021P. CUST has a value of zero, even though I keyed the value 1 into the screen. Ah, that’s it! The author of the program should have chained with #CUST, the field in the display file. Problem solved!
I click on the green arrowhead in the debugger to let the program resume, switch to the 5250 session to end the program, and the debugger lets me know in a pop-up window that the program has finished. I select the End Debug option from the Debug menu.
At this point, I change the source code, recompile, and begin again with Start Debug in the Debug menu. I will do this over and over until I’ve fixed the program and no longer wish to debug. Then I close the debugger and move on to my next task.
It’s a good little debugger. It debugs ILE and OPM programs (be sure to set the debugging options appropriately when creating a program), Java, and programs that run in PASE. It’s got a tiny footprint and is simple enough to use intuitively. I’m grateful to IBM for giving me a way to access it from ACS.
Wow. I didn’t know that was available! I use ACS Run SQL Scripts quite a bit. I added a button for Run SQL Scripts to the 5250 session to make it more convenient to access.