After the introduction we had with the previous posts and the compiling details, see the links:
I would approach a bit one of the most powerful features of RDI, the debugging. I am sure I couldn’t be exhaustive because the argument is complex and articulated, but I will cover the most important aspects able to let you work on it in your daily activities.
The main way to execute a debug on RDI is to work by Service Entry Points. You have the possibility to choose an LE program to start, it doesn’t matter if it is batch, or a web service or a service program and you could immediately activate all the debug options that RDI include, we will see it later.
But how to debug when SEP doesn’t works? For example for an old RPG program or when the program is running, like a never ending program. In these cases you should choose one of the existing configurations that RDI offers and work by it. In this post for a short exposition I would show you about Interactive debug and debug by Processes adding to SEP.
First have a look at this screen, where you could see how to launch the Debug Configuration Panel:
You will see all the available kinds of debug that you can activate adding to SEP:
DEBUGGING ON RDI BY SEP (Service Entry Point):
When you want to debug a LE program, the first think is to set the entry point by right click on the object list:
or by using the menu on the SEP Tabbed:
This panel will be opened and you must indicate the program (or the service program), the library and the User ID.
The debug will be activate when that user will launch the program.
If you confirm you should see a Confirm window and your program/SEP listed in the tabbed:
Every SEP could be managed by activation/deactivation, update and other options into the menu. For example, in case you recompile the program you should only UPDATE the SEP:
At this point you should start your program and then the debug will be activated.
You should do this by launching interactive debugging or by calling the program directly. Let us see the first case. Right click on the program and execute the interactive debug:
A warning window asks you to activate RSE Server by a CL program:
Sometime this command doesn’t works, maybe because the firewall blocks it:
So we could call the program directly:
Immediately RDI answers asking to pass on Debug View:
And we are in the debug view with our program opened and ready for debug:
There are a lot of different options to use the debug. For example to navigate inside program jumping from a brekpoint to another you could use F5/F6/F7 to move on, to pass on and to move back to a breakpoint. F8 will let you continue the process:
On the right side you could see the variables. You are able to change their value and you could select an expression in your code and test it:
You could add or remove breakpoint by double-click on the row:
Or you could change the breakpoint by adding conditions:
Another possibility you have is to the code execution step by step with the following options related to the velocity of the execution:
DEBUGGING ON RDI BY INTERACTIVE DEBUG:
Coming back to interactive debug I want to show you what happens when RSE starts normally. I launch it by main menu:
A window asks me to start RSE server:
and in the 5250 session the program is automatically executed:
RDI asks you to switch in debug view:
And as the previous case the debug view is opened with the program to debug:
DEBUGGING ON RDI BY PROCESSES:
Another easy way you could use for debug, especially when SEP doesn’t works, is debugging by processes. You could easily select your process inside the active processes of the user:
Then you could execute the debug as an IBM i job:
As the usual RDI will ask you to switch to debug view and then, after you will call the program in the same process you indicated, the debug will be activated and ready to be used.