The first thing that dawns on me is the relative ignorance of the user base with regard to the options for developing applications on the i with a rich IDE like RDi, as opposed to something like the old tired SEU. RDi and it's predecessor, WDSC, have been available for years, and provide a much richer development experience than SEU. Face it folks, this is the 21st century (has been for a while) and we should all be using 21st century tools. The second thing that amazes me is that it's a big deal that the new RDi runs on machines with 512M of memory. Folks (I like that word today) go read Joel Spolsky's blog about writing better code, especially #8 and #9.(and he puts his money where is mouth is). 512M? I think I have that on my video card!
Into the actual presentation... First part is an overview of the RDi tool. RDi is based on Eclipse and as such has all the features of Eclipse; this includes perspectives, GUI interface, drag/drop, keyboard shortcuts, etc. Again, the fact that this is cool and needs to be highlighted shows the current state of development tooling in the i community. For those of us in the Microsoft community using Visual Studio, or for many Java developers, having to highlight these capabilities is like having to highlight that the room you're sitting in today includes gravity and oxygen -- "like, no d'uh"as my kids would say.
Important step, you've got to start the "debug server" on the i. Since RDi is running on your PC, and the PC (obviously) can't run IBM i programs (RPG, Cobol, etc.) the program must run on the i; and there must be some sort of interface between the program being debugged on the i and the debugger running on the PC. The Debug Server is this interface. One Debug Server can handle all the programmers on the machine, so it only needs to be started once. It can be started from the command prompt too (STRDBGSVR), so you might as well just put it in QSTRUP and forget about it, at least on partitions that have active development.
OK, now we're getting to the meat of the presentation, an example program that Charlie will be debugging from within RDi. We're going to debug a SAX XML parser written in freeform RPG (so much for simplicity :-)) . The program seems to read a table to find the list of files in the IFS to parse, and then for each file found, parse it, and do something. To debug a program you simply right-click on the program and select debug. You need to have compiled the program with DBGOPT(*SOURCE), but that should be your default compile setting anyway. You set a service entry point and then click ok. This then connects to the debug server on the i and starts your debug session. A nice feature here is you can actively debug multiple jobs at the same time, remember you're limited to one STRSRVJOB at a time on the i. When you started the debug session you specified a user profile; this user profile tells the i what job(s) to debug. The i will debug the next call to the specified program by the specified user. This is how RDi, the debug server, and the green screen are all linked together.
From w/in RDi you now have access to the program in debug mode. We can do the typical things we would expect to do in a debugger. We will see the variables and the source. We can step though the code with F6 (was F10 in STRDBG) and jump out with F8 (F12 in STRDBG). A nice feature here is that you can click on the "blue dot"on the right side of the screen, and the editor will jump to the current line. Also on the right side are a number of icons that will show you different views, like breakpoint view, or variable view. Of course, being Eclipse based, I'm sure you can rearrange these windows any way you want. RDi also includes the ability to hover over a variable and see the current value. Typical rich IDE debug stuff, but a nice addition to the tools a typical i developer is used to.
This is where things start to go wrong for Charlie -- and while it wasn't my fault it's kind of funny that it goes wrong after I asked him change the value of a date field to '2009-02-30' using the debugger. Actually, until now he's been using a Verizon aircard to connect to his machine in his office so he could show us the use of RDi live. Unfortunately the Verizon coverage around the Fox just isn't up to par and the connection dropped several times. So off to the slides now. Thankfully Charlie is prepared enough to have slides to show. But a nice addition would be to actually record a debugging session with Camtasia and then we could have seen it in action, even w/out a connection. This is also when my netbook's battery died, so the rest is from memory; and I've got poor memory. :-) From slides Charlie does show several steps in the debugging process, but he really needed that connection.
Overall, RDi does provide a much richer interface for debugging (and coding) applications for the i, and everyone should be running it. It's a shame that companies aren't willing to spend the $800 for the tool, and the $500 for the machine to run it. After all they're spending 80 to 100K on each of the developers writing the code, and that's a yearly expense, where the tooling and hardware would be amortized over several years.
In conclusion, great job Charlie. Just wish Verizon had behaved more!