If you read the previous article of this series and concluded that the pros outweigh the cons, it's now time to learn the rules of coding in free-format. Don't worry, they're few, and most are common sense!
For the compiler to correctly validate and compile your code, there are a few rules that you have to follow, just like the fixed positions that you already know. These rules will become so natural over time that you won't even think about them. Let's review the rules one by one, and then look at a simple code sample:
- Obviously, you can write code wherever you want in free-format, between columns 8 and 80. Just make sure to leave columns 6 and 7 blank.
- In order for the compile to recognize free-format code, each block of it must be enclosed in the /FREE and /END-FREE directives. However, note that if you're running V7, there's a PTF that, among other things, removes this restriction. (I'll talk about it in a later article.) And yes, you can mix fixed- and free-format code in the same source, even in the same routine or procedure.
- Your statements can span multiple lines, but only one statement, no matter how short, is allowed per line. This is especially helpful when calling functions with long parameter lists or with nesting functions.
- To help the compiler figure out where your instruction ends, you must end it with the semicolon (;) character. (Note that I'm referring to an "instruction" instead of a line of code because it can now span multiple lines.) It's really a pain at first, but it will (hopefully) become so natural that you'll do it without thinking.
- Each instruction now starts with its respective operation code, even those that require Factor 1 to be specified. The rest of the structure remains the same, without the positional constraints. The "new" structure is <Operation Code> <Factor 1> <Factor 2> <Result>.
- You can have code instructions and comments in the same line. Just be sure to end the instruction with a semicolon and prefix the comment with double slashes (//). You'll see examples in the next TechTip that will make this clearer.
- Some operation codes are not supported in free-format. (I mentioned this earlier, but it's important because it will be a pain, even bigger than getting used to ending code statements with semicolons.) Don't worry; I'll go over the full list of these operation codes later in this series, providing free-format-compatible alternatives.
- Since there aren't fixed columns (between positions 8 and 80, at least), those old friends the positional indicators (used in some operation codes with varied functions) are not supported. If you've read some of the previous TechTips of this series, namely the one about getting rid of file-related indicators, though, this shouldn't be a problem for you. Again, I'll illustrate this with a few examples of operation codes in fixed- and free-format.
Don't be alarmed by the number of rules. It might seem a lot right now, but with some examples and a bit of practice, they will seem logical. Let's try to consolidate the rules with a simple example, in fixed- and free-format.
A First Taste of Free-Format Code
If you skipped directly to this section, please read the rules from the previous section. It'll make the task of fully understanding what's going on much easier.
Here's a typical RPG operation: reading a file and writing its contents to a printer file. I'll skip the H- and F-lines because, for the moment, I'll keep using the fixed-format specs that you're used to. I'll cover those very exciting changes that make RPG (almost) completely free-format later in the series. I know I keep saying this, but it's impossible to discuss everything at once!
This is familiar fixed-format code:
C EXCEPT HDR_REC
C READ MYFILE
C DOW NOT %EOF(MYFILE)
C EXCEPT DET_REC
C READ MYFILE
C ENDDO
Here, it becomes free-format code:
/FREE
EXCEPT HDR_REC;
READ MYFILE;
DOW NOT %EOF(MYFILE);
EXCEPT DET_REC;
READ MYFILE;
ENDDO;
/END-FREE
The most notable differences, other than the obvious column-free style, are the /FREE and /END-FREE directives and the semicolon at the end of each line of code. There's another subtle difference that's not mandatory (for the compiler at least) but that dramatically increases readability: indentation. Notice how I indented the two lines of code inside the DOW block; simply adding two blank spaces before those lines makes it immediately obvious that they belong to the DOW block.
This is just a simple example to get you a first taste of free-format. The next TechTip will provide more of them and discuss a few more subtleties of free-format that you need to be aware of. Until then, share your thoughts and doubts in the comments section below.




Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online