On 10 November 2016 at 13:57, Joni V. <joni_vanderheijden@xxxxxxxxxxx> wrote:
We use and enforce the use of RDi for development, since it's a lot more user friendly and SEU doesn't play well with today's RPG coding. But debugging, that's an other thing. Almost everyone falls back on the classic green screens for debugging, since the RDi debugging is just so tedious.
When I debug an ILE RPG program (this is all from memory; my machine
is backing up right now):
1) I have a filter or connexion for 'this project' which has only the
source members I'm working with. Typically, the program I'm about to
debug is open in the editor, but that's not a requirement.
2) I right click the source member in the RSE view, choose Debug > Set SEP.
3) On a 5250 terminal session, I run the program. This may be via a
menu, a CLP, or even directly off the command line.
4) The program begins to run. RDi switches to the Debug View, and
stops before the first line of code.
5) I set breakpoints, and also I set monitors on variables I want to track.
6) Step, Run to Location, or Run (with a conditional breakpoint set)
until the code reaches the place I need to inspect.
7) Once I figure out my problem, I click the red 'Stop' icon at the top.
8) The 5250 session goes back to the command line/menu/etc.
9) In RDi, I edit the code, compile with Ctrl-Shift-C. Then I right
click on the program in the SEP view and tell RDi to Refresh.
10) Back to step 2.
There are several things about my environment that make this easy.
1) I have *ALLOBJ; authority is not an issue.
2) I can (and do) copy production data to my library, which means I
can run with UPDPROD(*YES).
3) The user profile I develop with is the same profile I run the program with.
4) The programs are all compiled with DBGVIEW(*ALL).
5) I don't generally need to break into an already-running program; I
can start at the beginning.
--buck
As an Amazon Associate we earn from qualifying purchases.