Skip to main content

5 Reasons to Use Free-Format RPG

Many RPGers have yet to move on from fixed-format code. Here are five reasons to jump on the free-format bandwagon

Back in 2003, about 10 years after the initial availability of RPG IV, we wrote “By Now, the Case for RPG IV Should Be a No-Brainer.” This was two years after the introduction of free-form RPG logic. Another 13 years has passed and we felt it was time to make a similar case for the adoption of free-form coding. So maybe we’re a bit late this time. But in our defense, free-format RPG did become available in a gradual fashion. While logic could be written in free format in 2001, free form declarations didn’t arrive until 2012. And it wasn’t until 2015 that full freedom was achieved, i.e. the ability to use all the columns and even to define what “all the columns” means—i.e., how many columns wide your RPG spec should be.

Still we see a lot of fixed-format code and hear from many RPGers who seem to still not be enthusiastic to jump on the free-format bandwagon. We hear “reasons” such as:

  • “Why bother—if it ain’t broke, don’t fix it” or
  • “I think fixed format code is easier to read” or
  • “I’ll do my logic in free form but SEU breaks if I use free form declarations” or
  • “It’s way too much work to convert all my existing programs to free form” or
  • (the saddest of all) “My manager won’t let me because he/she doesn’t understand it.”

So we thought it was time to lay out what we see as the major advantages of free format RPG. Spoiler alert—we saved the best for last!

1. Indented code is more readable

When writing free format logic, you can indent the statements to show the structure of the code. The code is more easily understood, especially in cases involving more complicated logic blocks, such as nested If statements, Select/ When statements, or monitor blocks or in complex data structures with nesting and overlays in use.

Why is it important for the code to be readable? After all, if it was hard to write, shouldn’t it be hard to read? You’d certainly think that was the philosophy that was in play when some of the code we have studied over the years was written! The easier the code is to read, the easier it is to understand. If you understand the code, you can make changes faster and those changes will be less error prone.

We can almost hear some of you exclaiming “But indentation is optional and, even worse, it can be done incorrectly—which can be very misleading and cause even more confusion than no indentation.” Agreed. Which is why RDi (Rational Developer for i) has recently added a great feature to format (or re-format) some or all the code in an RPG source member—with preferences you can set such as how many blanks to use for indentation. You can read about it here. Also, the RDi plug-in for the Linoma Software RPG Toolbox has had an RPG re-formatter tool for some time. 

2. More efficient use of space in source code

Most RPG IV developers seldom use the Factor 1 column. At the same time, because we are no longer limited to simple arithmetic operations, many expressions—especially those involving built-in functions—get quite lengthy, often requiring multiple lines to complete. Consequently, fixed format code often wastes large amounts of space on the lefthand side while the right side is complicated with many multi-line statements. Using free format logic, there is much more space for expressions. Edit screens are “cleaner” and we can see more logic at a time because there is less need for multi-line statements—unless, of course, the programmer chooses to use multiple lines to make the code more readable.

Free form declarations allow for more efficient use of space. This is particularly true when defining a variable whose name doesn’t fit into the 14 character D spec column. Sure, you can do that using the ellipsis (…) and continuing on the next line but that not only wastes space, we find it just looks so awkward.

We find now that we’re using free form declarations, we’re more likely to create longer more meaningful names for variables and procedures. Not that we set out to deliberately create long names, but it’s nice that we’re not required to think of an acceptable abbreviation for “ProcessCustomer” or “ErrorMsgDisplay” just to avoid the dreaded ellipsis or, worse still, the short cryptic old-RPG-style names.

3. New features in free form only

Some new language functions are only available in free format logic. This is because a column-oriented language such as traditional RPG puts severe limitations on some kinds of new features that require significant space in the statement for implementation.

Our favorite examples include two free-form-only ways to replace KLIST to specify keys on a CHAIN or SETLL. We usually simply supply the key values—in the form of variable names or literals or expressions—in parentheses following the operation code. There is also a %KDS built-in function which is similar to but more flexible than the old KLIST.

Another example is the use of the %Fields function to specify a subset of fields which an UPDATE operation should affect. This is much more straightforward than using O specifications with the EXCEPT operation.

4. Easier to code and read declarations (especially for files)

We must confess that we have always hated F specs. Trying to remember what every letter in every column means and which are required is painful, even with time-consuming prompting. Barbara Morris (leader of the RPG compiler development team at IBM) once described reading and/or writing F specs as requiring the use of a secret decoder ring. We nearly always resorted to copying an F spec from somewhere else rather than figuring out what columns must be filled in and with what letters. That practice did occasionally result in surprises and lengthy debugging sessions due to the fact that the F spec we copied had some feature specified that was not what we needed—or vice versa.

No more copying of F specs for us! We can now easily define the meaningful keywords that we need for any file. Even better than that, we aren’t required to code all the keywords. Intelligent defaults for the keyword values mean that we aren’t required to specify that our files are externally described or that our printer file is output-only!

Reading free form file declarations is also far easier thanks to the keywords. Since file and data declarations can now be intermixed (i.e., files need not all be defined first), it can also be easier to identify data declarations that relate to file declarations because they can appear together in the code—the DS that is used to READ or CHAIN data into, for example, or the definition of the INFDS (information data structure) for the file.

5. Attract new programmers to RPG

Last, but not least, free format coding brings RPG more in line with other modern programming languages, all of which are free format. This is important for attracting new developers entering the marketplace. Traditional fixed format RPG is simply odd in a world of free format languages and gives RPG the undeserved appearance of an old-fashioned language not up to modern application tasks. RPG is a powerful and flexible language that many young developers come to prefer over other more popular language options for business applications. But they must first be attracted to learn it. Interestingly we have found that, once convinced of the benefits of a business oriented language such as RPG, most have no problem having to go and work with the old fixed format code. But had they been introduced to the language that way most would never have taken the time to appreciate it.

If you’re an RPGer who’s thinking “Won’t attracting new, young developers to RPG threaten my job?” we talked with management in several RPG shops about the possibility of changing languages—and in the process, possibly moving off IBM i altogether—simply because good RPG developers are too hard to find and/or too expensive to hire. It’s not because RPG doesn’t meet their needs—it’s that they are concerned about the future of enhancing and maintaining the applications with a workforce approaching retirement age. As it turns out, not attracting new developers to RPG is very likely a more real threat to your job and your coding legacy.

Our advice to shops who are having trouble finding RPG talent is to stop searching for RPG talent/experience. Instead, search for good business-oriented developers in any language and then teach them RPG (free form, of course) and IBM i. If you want to read more on our thoughts along that line, check out this blog post

What About Those Objections?

Hopefully, the points above have addressed our response to the the first two reasons for avoiding free form RPG that we listed at the beginning. As to the “SEU breaks” issue, you can probably guess our response to that—you really should be using RDi for development anyway and it fully supports all the latest RPG features and will do so in the future. SEU will only get further out of date as time goes on.

As for the issue of converting a lot of code, we don’t suggest that you move your code to free format manually. As much as we love free form RPG, that would almost certainly not be worth the time investment to convert the code by hand. Instead, use an automated tool to do most, if not all, of the conversion effort. The RDi editor has an option to convert RPG logic (but not the H, F, D or P specs) to free format. However, it’s a rudimentary conversion that isn’t likely to convert nearly as much of the code automatically as you will need. So we don’t recommend its use unless the code you’re converting is already fairly modern in its style.

Other tools are available that can automate at least most of the work. The ones we have some experience with are the RPG Toolbox from Linoma Software and the ARCAD-Transformer RPG from Arcad Software. Both of these support the option of converting not only logic but also your declarations if you want and both have plug-ins for RDi. We think tools like that have a great ROI given the amount of time they can save over doing the task manually. If you still can’t justify the cash for a commercial tool, consider Craig Rutledge’s open-source conversion tools a collection of commands that can be used to convert both logic (look for the JCR5FREE command) and the more recent V7 free form features (look for a group of commands under “Free H F D”). They don’t plug into RDi and they require more manual work than using the commercial tools, but it’s hard to beat the price.

As to the final issue—the out-of-date manager—perhaps you could forward this article to him/her.