Why RPG Developers are Adopting RDi
In more and more shops, Rational Developer for IBM i (RDi) is rapidly taking over as the development platform of choice for RPGers
Not long ago, walking into an IBM i development shop meant seeing a sea of green code on black backgrounds. These days, green screens for coders are a vanishing breed. In more and more shops, Rational* Developer for IBM i (RDi) is rapidly taking over as the development platform of choice for RPGers—and the pace of the migration seems to have accelerated significantly in the last year or so.
While we could easily list dozens of reasons why people are moving to RDi, we’ve decided to focus on five primary reasons that we see influencing developers to finally abandon their green screens.
1. You Can See More Code
The trend in today’s RPG shops is to write new code in a more modular, function-driven style. The fact remains though that most shops also need to maintain members with thousands of lines of older-style code. The more code a developer can see on the screen at once, the easier it is to understand the flow of the logic. With the RDi editor, the number of lines you can see is limited only by the size and shape of your monitor. On our larger desktop monitors, we can typically see 3x to 4x more code.
The RDi editor interface also allows having many members open at once. That makes life much easier when switching between source members to follow a program call chain. This is also important when moving between the code in those new smaller functions and their prototypes. A simple click on the tab quickly switches between the source members.
Sometimes it’s easier to work with multiple source members at once in a split screen. The RDi editor can be split in horizontally and/or vertically as many times as the monitor size and shape makes practical—and all members in a split screen can be open for edit. By contrast, the green screen has a browse-only limitation for a second member.
RDi offers another way to see more active code on the screen: You can eliminate from the view any lines that are not active lines of code. Comments and commented-out lines of code can be easily filtered from the view from a simple context menu option: Filter > Code.
2. Information at Your Fingertips
Many programmers quickly become addicted to the outline view in RDi. It’s a valuable source of information about our code. The outline provides quick access to details of the definitions of all our variables, even those from externally described files, and shows the layout of any data structures. It also provides lists of subroutines and procedures as well as a list of files, complete with their complete record layout details. Prototypes for called programs or procedures are also included in the outline. All that information means we don’t need to spend time looking for all those details—it’s all right there in the outline next to our source in the editor.
The outline view also offers a complete cross reference of everywhere in the code that any of those items are used in the code. In the case of variables, it highlights references where the variable’s value may be changed as indicated by (M) versus where it’s only referenced.
All the information in the outline is connected to the editor. For example, clicking on a variable name positions the editor to place in the code where it is defined, while clicking on a cross reference line for a variable positions the editor to that line of code. By doing so, the outline can be used as a navigation tool as well as a fount of information about the code.
The editor now provides access to much of the outline’s information via hover text. Not only can hover text show the definition of a variable, it can now also show the context of that definition, e.g., if it’s part of a data structure, it includes the DS name or if it’s externally described, it includes the file name(s). Prototyped calls have hover text showing the parameters to be passed (and value returned, if any) and includes details such as whether the parameters are declared as constant.
Hover text will now even show comments associated with variables, routines or procedures. Comments in the code immediately before the definition and end-of-line comments on the definition show up as well. Finally, an editor feature that encourages RPGers to include more comments in their code!
3. Code Navigation and Understanding
We’ve seen how the RDi Outline View can assist in navigating through a program, but several other features provide even more support for code understanding and navigation.
One of our favorites is implemented via a relatively little-known keyboard shortcut combination. To understand how it’s used, we’ll describe a brief usage scenario.
Let’s say you’re reading some program logic when you come across an EXSR (execute subroutine.) In most cases, the next thing you need to do is to go and look at the subroutine code—after which you’ll want to come back to your current location so that you can proceed with studying the rest of the code. We can think of several ways to quickly navigate to the called routine. However, easily and reliably getting back to this current point is trickier.
Here’s what we would do in RDi: After positioning the cursor on the name of the subroutine, press F3. (It may feel like this will exit editing the source, but it won’t.) Your cursor will be positioned to the beginning of the subroutine. If you check the message line at the bottom of the editor window, you’ll see that it offers you a hint for how to get back where you came from—“Press Alt + Left/Right arrow to switch between the previous and the current location.” That message will disappear if you move your cursor within the code, but keep it in mind because it will still work when you’ve finished studying the subroutine logic. Pressing Alt + Left arrow will position you back on the original EXSR statement, ready to continue your perusal of the rest of the code.
This navigation feature works not only for subroutines, but also for internal procedures and data definitions. If you hover over a variable and learn from hover text that it’s part of a data structure, you may want to navigate to the data structure definition. While you could click on the hyperlink to the definition in the hover text, that wouldn’t provide the quick link back to your current location. We prefer to press F3 on the variable name to be positioned on its definition in the structure. We can subsequently use Alt + Left arrow to return to the original position in the logic.
If you forget that it’s F3 you need, you can use the context menu (i.e., right click on the subroutine name) and choose Source > Open Declaration.
Another tool to help you understand the code you’re editing is the ability to (re)indent any free-format nested logic according to your own preferences—just in case you run into some logic whose current indentation doesn’t make the structure obvious. This is done via Source > Format from the editor context menu.
Nested logic that’s still in fixed format is an even bigger challenge. The Show Block Nesting feature in RDi draws arrows to help illuminate nested logic.
Show Block Nesting highlights nested logic in fixed format RPG code. This can work on an entire subroutine or procedure or for a specific block by positioning on either the beginning or end of a code block or even on an ELSE or WHEN or OTHER statement in a block. Use Source > Show Block Nesting from the context menu or the shortcut Ctrl + Shift + O. There are other tools to help make fixed-format nested logic more understandable, but this is our favorite.
4. Speed of Finding and Fixing Compile Errors
We have yet to meet anyone who writes code so perfectly that it all compiles with no errors on their first attempt. The green screen method of finding errors after a compile attempt is quite cumbersome, something we never thought about until we began teaching developers who were new to RPG and IBM i how to find and fix their compile-time errors. It requires opening a spooled file, locating the section in it where the errors are reported and then determining which line of code is impacted in the source for each error, and finally positioning to that line of code in the source member—all before you can even begin to figure out how to fix the error.
In RDi, a compile action immediately and automatically reports any errors in a special Error List, which is by default positioned just below the editor window in the workbench. A simple double click on a specific error in the list positions the editor to the offending line of code. Once there, the outline and navigation features covered above can speed up the process of figuring out how to fix the problem. You can also control which errors are shown in the editor and how they are marked in the source.
5. Full Support for Today’s RPG
The RPG language continually evolves to keep up with the needs of today’s businesses. IBM hasn’t updated the language support on the green screen SEU editor in over 10 years so it cannot understand all of current RPG syntax. Developers who want to take advantage of all the great new features in the language tend to gravitate to a tool that understands those features. RDi is the only editor being enhanced by IBM to keep up with the latest enhancements to RPG and other languages.
The green screen editor falsely reports syntax errors when using newer RPG features such as free-format declarations. Not only does RDi understand and accept the modern syntax, it also contains features such as Content Assist that can aid developers in learning and using the new declaration types easily.
Free-format declarations, which have been part of RPG for more than four years now, are the most obvious of the RPG features that result in false syntax errors in SEU. There are also at least eight built-in functions, two op codes (in addition to all the op codes for free-format declarations) and many new keywords enhancing previous RPG features. With each new release, the gap between RPG’s syntax and what SEU supports will continue to grow. To take advantage of all that modern RPG has to offer, it makes sense to use an editor that understands all its features and can assist you with the syntax to use them.
Just the Beginning
There are many other things that motivate former green screen developers to make the switch—and even more things that keep them there once they see what RDi can do for them. If you’ve been thinking of trying RDi and could use some pointers on getting started, you may want to download our RDi Quick Start Guide (bit.ly/2BPXuqe ) and our cheat sheet of favorite keyboard shortcuts (bit.ly/2SxyF8f).
For those who made the switch to RDi but haven’t yet upgraded to version 9.6, you’re missing out. The past year has seen the introduction of a wealth of new and enhanced features you don’t want to miss.