Although the name is nothing short of horrible, the latest edition of the Rational tools finally gives i developers the tools they need.

Even those of us who love Rational Developer for i (RDi) have been clamoring for an alternative to the venerable Screen Design Aid (SDA). It's been especially frustrating because the feature was already there in the tool. It was even called Screen Designer! It was right in front of our eyes, but it had that dreaded "Technology Preview" tag associated with it, along with a big disclaimer that it was not to be used for production work. Well, in the new Rational release, the preview tag is gone. Not only that, we got an extra bonus: a printer file designer (called the Report Designer)! In fact, this article is all about bonuses for the green-screen developer, so jump in!

Rational Developer for IBM Power Systems

And that's not even the whole name. The full name is Rational Developer for IBM Power Systems: RPG and COBOL Development Tools for the i. I can't even figure out an acronym for that mess. I'm going to stick with RDPi until further notice. The similarity to the old RDi acronym is intentional; RDPi is very much a rebranding of the RDi tools, although, of the bits they've added, a couple are absolutely essential to ongoing i development.

Screen Designer

The first enhancement is not really new, but they've finally taken the "Preview" off of the Screen Designer technology. That means that you can finally use the designer in a production environment. I've written about the screen designer in the past. I referred to it in an earlier review of RDi-SOA, and I wrote an in-depth review of one of the early versions of the tool back in May of 2007. Much of that review is still valid, although the look-and-feel of the tool has changed drastically. The 2007 version in particular is different because it had the UI characteristics of WDSC; the newer Rational products have a crisper UI because they're based on a newer version of Eclipse.

You might wonder why there hasn't been a lot of obvious change in the tool in the last two or three years (I say "obvious" because while a lot has happened under the covers, the interface is still strikingly similar to the release from back in 2007). In my opinion, it's because there really wasn't that much that needed to be changed. The basic GUI approach that IBM took back in WDSC was a good one. In order to provide the same level of functionality as SDA, the primary requirement was to expose the valid keywords for the various elements of a display file in a rational manner, and that was done way back in the WDSC version. After that, the real work was in refining the UI, especially the WYSIWYG design aspect.

Don't get me wrong, though: the Screen Designer is more than just a GUI version of SDA. A couple of features give the new tool a marked productivity edge over SDA. In particular, the ability to group records into record sets (called a "screen") is a significant improvement over SDA. With this new feature, you can combine a subfile record, a subfile control record, and a footer record into a single screen and then display them simultaneously. The "active" record (the one you can make changes to) is shown in color, while the other records are gray. But the real trick is that the active records are shown in a list in the GUI, and by simply clicking on one, you make it active and make the others inactive. Contrast this to what is required in SDA (exiting out of the design page, selecting another record, gong back into the designer), and you'll quickly see that the new tool is easier.

Figure 1: This is the Screen Designer, in all its production-ready glory. (Click images to enlarge.)

But the other issue is that the person responsible for the Screen Designer (and the Report Designer) is also the same person responsible for the Rich UI Designer in RDi-SOA. If you've played with EGL Rich UI at all, you'll know that Brian Farn is something of a rock star when it comes to UI designers. However, that particular project kept him from moving the Screen Designer into production. With the new release, he's finally gotten the chance to add the necessary features to release the tool. And at the same time, he's given us yet one more tool....

Report Designer

I'll let you in on a little secret if you promise not to tell anyone: I still use internally described printer files. For a number of reasons, some of which probably have as much to do with inertia as anything else, I find it much easier to slap together a bunch of output specifications than to go through the effort of creating a PRTF source member, adding record formats for the various parts of the report, adding literals and variables, going through the separate compilation process, and then finally using that in my RPG program.

I know it probably seems silly; I have no such desire to use internally described display files. Then again, that's a little bit of an apples-to-oranges comparison since even with an internally described display file, you still have to create the display file object. With an internally described printer file, you don't need the extra object; in the simplest case, you can just use a system-supplied printer file object like QSYSPRT.

Anyway, while I have used externally described printer files, in general I just don't find them productive enough to justify the change in my programming style. That may finally change, however, with the new Report Designer. Let me just show you a couple of screen shots.

Figure 2: The Report Designer looks a lot like the Screen Designer.

You can see that the Report Designer definitely inherited a lot of its good looks from the Screen Designer. The WYSIWYG editor with the drag-and-drop palette and the ability to combine records (in this case, into reports rather than screens) are almost directly equivalent to their counterparts in the Screen Designer. The WYSIWYG part is consistent and pervasive: for example, you can click on a field, and a sizing box will appear, letting you change the size of the field. You can click on a literal to directly modify the literal value. Right-click and select Properties to modify every attribute of the field.

Just those features would be nearly enough to get me to switch. But the Report Designer adds one more feature that seals the deal for me. You can create a "report layout" that includes one or more records (including multiple instances of each) and set the values of the fields and indicators for each record. In the case of this simple report, it allowed me to easily create the following test layout.

Figure 3: Here is the report from Figure 2 with test data added.

Changing the data is simple: just click on the field on the report and modify the test data. You enter non-formatted data for numeric fields and the system does the formatting based on the edit codes or edit words associated with those fields. This allows you to get an immediate visual feedback of how the report would look without having to actually compile and test it using an RPG program. I can almost guarantee that this will provide users with an incredible productivity boost in their report definition.

The Report Designer isn't a silver bullet. For example, it didn't display any of the advanced directives in an AFPDS printer file. I haven't asked Brian yet if that's even a direction they plan to pursue. But for standard text reports, this is quite an advancement over the old RLU.

So there you have it: two excellent tools, one new and one improved, specifically designed for the legacy i community. I must say I'm pleasantly surprised. The only thing left is a replacement for STRSQL. And for that, you'll have to read my upcoming article on IBM Data Studio.