There are two primary reasons that I've not been a strong advocate for the free-format RPG IV syntax that was introduced with OS/400 V5R1:

1. Most people were running OS/400 V4 and therefore would not be able to utilize any of the example code I wrote about.
2. The syntax was too different from what I was used to.

Let me explain these reasons.

First, until recently, most people were running one of the OS/400 V4 releases. Sure, a large number of shops moved to V5R1 within a year of it first being announced, but of those, a large number also had secondary systems installed and had to be compatible with V4. So V5R1-specific features wouldn't cut it.

Second, I feel that the syntax used in free-format is a bit more of just "make it work" than it is "make it right." I find that even today with V5R5 on the horizon (yes, I said V5R5) I'm still struggling every time I allow myself to write with /free syntax.

Certainly, many others jumped on the /free bandwagon right way. These people were from many different backgrounds and cultures. Some were former C, Visual Basic, or COBOL programmers who are used to free-format syntax. Some were instructors who benefited by being able to fit their examples on their PowerPoint slides when free-format was used. Others were leading-edge iSeries professionals who always jump on the latest features.

Today, some people say, "Most of the shops I see are using /free." I have a pond in my back yard, and most of the ducks I see are mallards, so does that mean most ducks are mallards? This is specious reasoning at its best.

In June 2006, however, most iSeries shops are running OS/400 V5R1 or later. This means most shops have the ability to use free-format RPG IV syntax if they choose to. Therefore, I have made a decision to use free-format RPG IV syntax where appropriate (but not 100%). I will use it where it is best used: in calculations specifications that require longer lists of parameters or in expressions (including built-in functions) that are a bit lengthier than usual.

Here are some guidelines I've come up with for writing /free RPG IV syntax:

• Use the // comment syntax.
• Force yourself to press the semicolon (;) key before pressing Enter. That way, you can always remove extra semicolons rather than never see them in the compiler error listing.
• Always use uppercase/lowercase letters.
• Always indent conditional logic.
• Always line up the ENDIF statement with its corresponding IF statement. The same holds true for the other conditional operation codes.
• Try to avoid mixing free- and fixed-format syntax in the same subprocedure or mainline calcs. While it is OK to have subprocedures in free-format and mainline calcs in fixed-format, try to avoid using both syntaxes in the same area of the program source code.
• Remember that IBM introduced the EVALR (eval right-justified) opcode back in V4R2. It copies data right-justified to the result. This is a way to get the MOVE opcode into your /free code without burning out your brain cells. The EVAL opcode is similar to the MOVEL opcode.
• Use %CHAR(myNumVar) to convert numeric data to character.
• Use %EDITC(myNumVar : 'X') to move numeric to character, unedited with leading zeros.
• Avoid symbols (such as @, #, and $) in variable or subprocedure names. Nothing's worse to read than code with a bunch of special symbols in field names. What's more, most of these symbols don't convert to other CCSIDs properly. So if you have a field named W#CNT and the source code moves to Italy, the Italian programmers are going to see garbage for the second character of the field name. Do you really want the extra work later on?

Gotcha!

I've also run into several gotchas with free-format. Most are minor, but a couple of these minor issues seem to occur with every RPG IV programmer who embraces the /free syntax.

Here are some of the gotchas I've run into while writing /free RPG IV syntax:

The MOVE and MOVEL opcodes are not supported in /free syntax. There are myriad built-in functions that allow you to accomplish similar function to MOVE and MOVEL, and you'll need to learn those functions.

Be sure you enter a semicolon at the end of every RPG IV statement. If you don't, you'll get an error on the next line in the program that makes little sense to you. This is because the syntax allows for automatic line continuations (which is good), but a byproduct is that the compiler doesn't know where the statement ends until it finds a semicolon.

So the following can give you headaches:

What's wrong here? The semicolon is missing from the first line. It should be:

As it was originally written, the compiler thinks it is the following:

This is illegal syntax in /free RPG IV. It's valid syntax in other languages, but not in RPG IV, so be careful or you might stare at your errors for days. The correct syntax would be:

You also need to pay attention to parens around conditional expressions. This technique is permitted on all conditional operation codes except the FOR operation. So the following DOU operation is valid:

But the following FOR operation is not valid:

The syntax does not support parens around the FOR operation's conditional expression. Although it's technically not an expression, in C, JavaScript, C++, and other languages, it is treated the same, so for (i = 1 to %size(myvar)) is valid in other languages, just not RPG IV. And since parens are supported around other conditional expressions, you could easily deduce that FOR supports them as well, but it doesn't.

Also, the syntax checker in SEU doesn't work with /free syntax until V5R4. The good news is that /free syntax checking is supported in V5R4.

Next, the /end-free directive is required even if you jump back into fixed-format. For some reason a "C" in column 6 doesn't imply that you've ended free-format and want to go back to fixed-format. You get a compiler error instead. I often include a "SET ON LR" statement at the top of my source code, but most people put it at the bottom of the calc specs. To make it stand out, I habitually code it in fixed-format. For example:

If I were to leave off the /end-free line, I'd get a compiler error. Again, this is a gotcha, not a design flaw. You could just as easily (if not more easily) have code like this:

Next, the /free syntax is evolving with each release. For example, the short-form math did not exist in V5R1; it was introduced in V5R2. In V5R3, IBM changed the way the short-form math works. So you have three releases of /free that support three different syntaxes for math.

V5R1:

V5R2:

V5R3:

What changed is that parens are now implied around the right-side values when short-form math is performed. In addition and subtraction, this doesn't have a big impact, but when multiplication is performed, it has a huge impact. For example:

This

means this in V5R2

but in V5R3, it means this:

For what it's worth, the new interpretation is the correct one, as the original parsing was clearly producing the wrong result.

If you're on V5R2 or V5R3, you can install and apply the following PTFs to make sure the parser is correctly converting the short-form math operator:

ForV5R3M0, use SI17150.

That's all on free-format for now. Watch for more on this topic in future issues of RPG Developer and on iSeriesTV.com, which premieres on July 18.