You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > DEVELOPER > RPG

The Case for a Modern Editor


In the last few years, more and more of our clients have asked for education on moving from PDM and SEU to the Rational Developer tools. And at the last two RPG & DB2 Summit events, we’ve offered a pre-conference workshop on the same subject—and it’s sold out both times well before the event. Clearly, many shops have already made the case for using a modern editor and for getting educated on how to use it effectively.

Yet we still get emails regularly from RPG developers asking us to help them make a case for the Rational toolset in their shop. In some cases, the writers themselves are not completely convinced; in others, the writer is convinced but is having trouble convincing management or fellow developers of the value.

So we decided that it’s time to make the case for a modern editor. If nothing else, it will simplify the email response to future inquiries on the subject—we can just send a link to this article!

What Tool Are We Talking About?

First, let’s get the terminology out of the way. We like to refer to the toolset that we use as RSE, the Remote System Explorer. That’s technically just one part of the product called Rational Developer for i (aka RDi). But since the product has gone through a few name changes over its lifetime, it does get confusing to use to the product name. RSE has been part of the Eclipse-based toolsets from IBM first in the product called WDSC, then RDi, followed by RDP and then back to RDi again. We warned you it was confusing! But through it all, RSE has been there. So that’s why we use that consistent term to describe the toolset—regardless of the actual product name.

Second, we’ve actually done the topic a disservice with the title we’ve used here—referring to “a modern editor.” That’s because RSE is way more than just a better editor. It is that, for sure; but it would be much harder case to make if it were just an editor. RSE is what is often called an IDE—Integrated Development Environment—or an edit/compile/debug tool. Read on to understand more about what that means.

Why RSE?

So why are we such fans of RSE? We don’t have nearly enough space here to answer that completely. But we’ll do our best to hit some of the highlights.

First, let’s focus just on the editor, what makes RSE better?

You can see much more code at a time in the RSE editor. The number of lines of code you can see on the screen is limited only by the combination of our monitor size and the font size we choose –not a pre-set, always fixed limit where the only benefit of a big monitor is bigger letters. We normally can see at least twice the number of source lines on the screen compared to SEU. And that’s on our relatively small laptop screens. At our desks with a bigger monitor, it’s closer to three times. The more code we can see at a time, the easier it is to follow the flow of the logic.

Need to open other members? Fine, just do it. Open as many source members at a time as you need and just click to move from one to another. You can also see them in split screen—either a vertical or horizontal split. We prefer the vertical split because we can typically see a full screen of code from two members at once versus the eight or so lines we see in an SEU split screen. You can even have multiple splits to see more than two members at a time if you want. The more modular our applications get, the more important it is to be able to work with code from many different source members at once. All the members can be open for edit (although we can certainly open them just for browse if we need to). Figure 1 gives you an idea of what you can do.

There is a wealth of filtering and navigation tools built into the editor. Do you have members with hundreds of commented-out lines of code? Just right-click in the editor and choose a filter to show just the code—the comment lines are instantly hidden. A filter by change date allows you to quickly peruse all the recently changed lines of code to spot potential sources of new bugs that may have surfaced.

If you’re following some logic and you encounter an EXSR operation (or internal subprocedure call), simply position the cursor on the routine name and press F3. Voila! You’re positioned to the subroutine (or subprocedure). But that’s not all—when you’re done looking at that logic, the Alt-Q shortcut key puts you right back at the EXSR or call procedure statement where you started. Try that in SEU.

More Than an Editor

To talk about some of our other favorite features, we’ll expand the discussion to include other tools integrated with the editor.

The Outline View shows all the field and data structure definitions, including the externally described fields. With one click, you can be positioned to the definition of that field in the editor. No more DSPFFD or using a more-than-a-little arcane Find command on a command line. For that matter, you don’t even need to use the Outline View to see the definition of a variable—simply hover over it anywhere it’s used and its definition pops up.

The Outline View does much more. It also shows a list of subroutines and subprocedures. Clicking on their names positions the editor to the routine. Also, for each variable and each routine in the outline, you can get a cross reference of every line that references it. Clicking on the cross-reference statement number positions the editor. That’s a boon to navigating in large source members. For variables, the cross-reference even shows which lines of code actually update the variable value rather than simply reference it. Prototypes appear in the outline as well so that you can see the variables needed to call a program or procedure. The outline now even keeps track of your source changes, updating the definitions and cross-reference information on the fly. Take a look at the Outline view in Figure 2.

Eventually after doing all this code editing, you’ll need to compile it—or at least attempt a compile. How often is your first compile attempt successful? When you use RDi to compile, you should leave your source member open in the editor. That’s because, just in case there are some errors, they will appear in a list that’s integrated with the editor. Position to an error and double-click to get directly to the offending line to code—way faster than any mechanism that you may use to find errors in a spooled compile listing. See what we mean in Figure 3.

We haven’t even touched on Content Assist or local verify with the editor or the true graphical screen and report DDS designer, or the graphical debugger with the capability to monitor the values of our chosen variables as we step through the code. And there are about 100 other things that we could list, but we must draw the line somewhere!

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters