Part three of getting started ILE RPG program addresses free vs. fixed and internal documentation. Read parts one and two here: Getting Started: Sections & a Sample of ILE RPG Programs and here: Getting Started: Building the ILE RPG Program and Navigating Legacy Code
Editor's Note: This article is excerpted from chapter 2 of Programming in ILE RPG, Fifth Edition.
Free vs. Fixed
As you can see, RPG’s free-format instructions have a more consistent, modern layout than do the fixed-format equivalents. If you are using free format, you’ll probably find it easier to concentrate on your program’s logic instead of its exact positional syntax. In addition, free-format operations allow you to use indentation to visually explain blocks of related code. You don’t need to remember which operation codes support which C-spec layout if you are using free format.
Version 5 supported free-format calculations, but it retained fixed format for other specifications. Release 7.2 introduced the remaining free-format instructions, such as Dcl-f (to replace F-specs) and Dcl-s (to replace some D-specs). Although you should use free format wherever possible, you can intermix free-format code with fixed-format code.
Before Release 7.2, it was necessary to code free-format calculations between /Free and / End-free instructions. These instructions, called compiler directives, direct the ILE RPG compiler to use free-format syntax rules for all the instructions within the block of code between the directives. This requirement became especially onerous if you mixed free- format code with fixed-format code, because RPG required that you constantly switch between modes. The following example shows how to use the /Free and /End-free directives. You must code them exactly as follows, beginning with a slash (/) character in position 7.
As you can see, mixing free format and fixed format makes the code unnecessarily jumbled and difficult to understand. Starting with Release 7.2, the /Free and /End-free directives are no longer required, but you should still avoid mixing the two syntax options unless it’s absolutely necessary:
Internal Documentation
You might think that after you have a program written and running, you are done with it forever and can move forward, developing new programs. However, a majority of all programming is maintenance programming rather than new application development. Maintenance programming involves modifying existing programs to fix problems, addressing changing business needs, or satisfying user requests for modifications.
Because the programs you write will most likely be revised sometime in the future, either by yourself or by another programmer in your company, it is your responsibility to make your programs as understandable as possible to facilitate these future revisions. RPG programmers use several techniques to document their programs.
Program Overview
Most companies require overview documentation at the beginning of each program. This documentation, coded as a block of comments, states the function or purpose of the program, all special instructions or peculiarities of the program that those working with it should know, the program’s author, and the date the program was written.
If the program is revised, entries detailing the revisions, including the author and the date of the revisions, usually are added to that initial documentation. For a program that uses several indicators, many programmers provide an indicator dictionary as part of their initial set of comments to state the function or role of each indicator used within the program.
Comments
Another good way to help others understand what your program does is to include explanatory documentation internal to your program through the use of comment lines. ILE RPG comments begin with double slashes (//) entered anywhere in position 8–80. In free-format specifications, these comments can comprise an entire line or a portion of the line. Once the compiler encounters the // characters, it ignores the rest of the line, treating the remainder as a comment. In fixed-format specifications, the comments make up an entire line and cannot include compilable code.
Comments exist within the program at a source code level only (not in the compiled object) for the benefit of programmers who may have to work with the program later. Include comments throughout your program as needed to help explain specific processing steps that are not obvious. In adding such comments, you can assume that anyone looking at your program has at least a basic proficiency with RPG; your documentation should help clarify your program to such a person. Documenting trivial, obvious aspects of your program is a waste of time. However, failing to document difficult-to-grasp processing can cost others valuable time. Inaccurate documentation is worse than no documentation at all because it supplies false clues that can mislead the person responsible for program modification.
Appropriately documenting a program is an important learned skill. If you are uncertain about what to document, ask yourself, “What would I want to know about this program if I were looking at it for the first time?”
Blank Lines
In addition to the use of comments, many programmers find that a program’s structure is easier to understand when blank lines break the code into logical units. To facilitate using blank lines within your code, ILE RPG treats two types of lines as blank: First, any line that is completely blank between positions 6 and 80 can appear anywhere within your program. Second, if position 6 contains a valid specification type, and positions 7–80 are blank, the line is treated as a blank line; however, the line must be located in that portion of the program appropriate for its designated specification type.
Chapter Summary
ILE RPG programs are written as fixed-format specifications or free-format instructions or a combination of both. Different specification forms convey different kinds of information to the RPG compiler, which translates the program into machine language.
The control options section provides default options for the program. The declarations section identifies the files and other data items the program uses. The main procedure section details the processes the program performs.
File declarations contain descriptions of all files used within a program. The file object contains a record format that describes the fields comprising the record. Printer files also contain record formats that depict the layouts of the printed lines on a report. Other declaration instructions describe data items that do not originate in a file, such as standalone variables.
The main procedure section contains instructions, or processing steps, to be accomplished by the computer. When RPG’s built-in cycle controls the execution of the main procedure, the program is known as a cycle main program. Each instruction includes an RPG operation code (by coding it either explicitly or, in the case of the Eval operation, implicitly in an expression) and can include additional operand entries, depending upon the specific operation. The computer executes operations in the order they are given in the program source, unless the computer encounters an operation that specifically alters this flow of control.
RPG source code is stored in a source file member with a member type of RPGLE. The CRTBNDRPG command compiles the source and creates the program object. The CALL command executes the program.
Early releases of RPG used fixed-format specification lines instead of free-format instructions. Although free format is now preferred, you can freely intermix free format and fixed format in the same program.
An important part of programming is documenting the program. Comment lines, signaled by double slashes (//) in nearly any position of a specification line, can appear anywhere within a program. You code most comments on a separate line, but in free-format specifications, you can include them on the same line as executable RPG statements, after the RPG statements. The ILE RPG compiler ignores such comments.
Within your code, you can insert completely blank lines and lines that are blank except for the specification type to visually break the code into sections.
The following table summarizes the operation codes and BIFs discussed in this chapter. Optional entries appear within curly braces ({}):
Want to learn more about Programming in ILE RPG? Pick up the book in the MC Bookstore today!
Jim is the president and founder of imPower Technologies, where he provides professional IBM i training and consulting services. He is active in the IBM i community, working to help companies train their employees in the latest IBM technologies and develop the next generation of IBM i professionals.
MC Press books written by Jim Buck available now on the MC Press Bookstore.
 |
||
 |
|
Control Language Programming for IBM i Master the A-Z of CL, including features such as structured programming, file processing enhancements, and ILE. List Price $79.95 Now On Sale
|
|
||
 |
|
Mastering IBM i Get the must-have guide to the tools and concepts needed to work with today's IBM i. List Price $85.95
Now On Sale
|
|
||
 |
|
Programming in ILE RPG Get the definitive guide to the RPG programming language. List Price $95.95
Now On Sale
|
|
||
 |
|
Programming in RPG IV Understand the essentials of business programming using RPG IV. List Price $79.95
Now On Sale
|
Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. 
LATEST COMMENTS
MC Press Online