Part two addresses the building of an ILE RPG program. It also demonstrates how to navigate legacy code. Review Part one here: Getting Started: Sections & a Sample of ILE RPG Programs.
Editor's Note: This article is excerpted from chapter 2 of Programming in ILE RPG, Fifth Edition.
Building the Program
To create this program, you use an editor, such as SEU or LPEX, to enter the ILE RPG code into a source file member with a member type of RPGLE. A source file member is a set of data within a source file. Usually, a source file contains more than one member, each of which holds the source code for a single program. Once the source member contains all the necessary code, you then use the CRTBNDRPG (Create Bound RPG Program) command to compile the source and create the program. Figure 2.3 shows the prompted CRTBNDRPG command. The compiler generates a listing, which you use to verify the creation of the program or to find errors. Appendix B describes the tools you might use to edit and compile a program.
Figure 2.3: CRTBNDRPG command
Once the program is successfully created, execute it by using the CALL command. The output of your program is a spooled file, CUSTLIST, in an output queue. You can view the report by using the WRKSPLF (Work with Spooled Files) command, or you can release it to a printer.
Navigating Legacy Code
Earlier releases of RPG (Release 7.1 and earlier) identify the sections of a program by using different kinds of lines, called fixed-format specifications. Fixed format means that the location of an entry within a program line is critical to the entry’s interpretation by the RPG compiler. Although you can write most modern programs by using free-format coding, which does not have significant positional restrictions, you may encounter fixed format when you are maintaining existing programs. Good programming style prefers free-format coding, but you can freely mix fixed format and free format within the same program.
Each type of fixed-format specification has a particular purpose. Following are the specification types:
- Header (Control) specifications—provide default options for the source
- File specifications—identify the files a program is to use
- Definition specifications—define variables and other data items the program is to use
- Input specifications—depict the record layout for program-described input files
- Calculation specifications—detail the procedure the program is to perform
- Output specifications—describe the program output (results)
- Procedure boundary specifications—segment the source into units of work, called procedures
Not all programs need every kind of fixed-format specification. Fixed-format specification types require a different identifier, or form type, which must appear in position 6 of each program line. A File specification line of code, for example, must include an F in position 6. For this reason, File specifications are commonly called F-specs.
Fixed-format specifications must appear in a specific order, or sequence, within your source code, with all program lines that represent the same kind of specification grouped together. The following list illustrates the order in which the specifications are grouped. Notice that the fixed-format specifications generally follow the same order as the free-format sections of a program.
* Beginning with Release 7.2, you can mix File specifications and Definition specifications in any order.
Most specifications require fixed-position entries in at least part of the specification. The editor you use to enter your source code can provide you with prompts to facilitate making your entries in the proper location. (Appendix B provides more information about editors.)
Even though specifications are primarily fixed format, some also support a free-form area, where you can code keywords and values with little or no regard to their specific location within the free-form portion of the specification. Beginning with Version 5, RPG supports free-format calculation specifications, but—until Release 7.2—all other specifications must be fixed format.
When you begin maintaining a fixed-format program, notice that an entry does not always occupy all the positions allocated for it within a specification. When that happens, a good rule is that alphabetic entries start at the leftmost position of the allocated space, and unused positions are to the right. Numeric entries, however, are usually right-adjusted, and unused positions are to the left.
Fixed-Format Specifications for a Sample Program
Let’s look at a fixed-format version of the example program and compare it with the free-format version shown earlier.
Notice that fixed-format RPG specifications do not require a semicolon delimiter. Fixed format traditionally uses an asterisk (*) in position 7 to denote a comment. You can also use slashes (//) to begin a comment in fixed-format code, but the comment cannot be on the same line as other code; it must be on a separate line.
Control specifications (Control options) require an H in position 6. The remaining positions, 7–80, consist of reserved keywords, which have special values and meanings associated with them. Fixed-format control specifications mimic the function of the Ctl-opt instruction in free-format code. The keywords have no strict positional requirements—they can appear in any order and in any position 7–80. The following header shows the layout of a Control specification for the fixed-format variation of your program:
File Description Specifications
The fixed-format File specification (F-spec) is comparable to the Dcl-f (Declare File) instruction covered earlier. All File specifications include an F in position 6. Each file a program uses requires its own File specification line. The following header shows the layout of a File specification and the completed File specifications for your program. Note that in addition to column positions, the ruler lines include prompts to help you remember where to insert required entries.
Filename (Positions 7–16)
In positions 7–16 (labeled Filename++ on the ruler line), you enter the name of the file. Note that you code filenames, like other alphabetic entries, beginning in the leftmost position allowed for that entry—in this case, position 7. Simply leave blank all unneeded positions to the right of the name.
File Type (Position 17)
Position 17 (labeled I on the ruler line) specifies the file usage. It is the fixed-format equivalent of the Usage keyword used by the Dcl-f free-format instruction. The two types in this program are input (type I) and output (type O).
File Designation (Position 18 Input Files Only)
Every input file requires a file designation entry (position 18, labeled P). File designation refers to the way the program accesses, or retrieves, the data in the file. In the example, you retrieve data by explicitly reading records within your program, rather than by using the built-in retrieval of RPG’s fixed-logic cycle. In RPG terminology, that makes the file full procedural, so F is the appropriate entry for position 18. Because this designation applies only to input files, you leave it blank for the Custlist specification line. The Dcl-f free-format instruction has no entry for a file designation. All files that Dcl-f declares are assumed to be full procedural files.
File Format (Position 22)
The next required entry is file format. An E in position 22 (labeled F) stands for external format, which means that the file’s record formats are implicitly contained in the file itself. Chapter 3 explains externally described files in further detail. The Dcl-f free-format instruction uses externally described files as the default entry, so no entry is necessary when you use Dcl-f to declare an externally described file.
Device (Positions 36–42)
The Device entry indicates the device associated with a file. You enter the device names left- adjusted in positions 36–42 (labeled Device+). This entry corresponds to the Disk and Printer keywords used earlier in the free-format Dcl-f example.
Keywords (Positions 44–80)
The Keywords area of the File specification gives you an opportunity to amplify and specialize the basic file description in the positional area (positions 6–43) of the F-spec. RPG allows many reserved keywords (listed in Appendix A) in this area of the specification. These are the same keywords that the Dcl-f instruction uses. You can code more than one keyword on a specification line, in positions 44–80, without being too concerned about other positional requirements. Most RPG programmers, however, prefer to limit their code to one keyword per line. If a specification requires more than one keyword, you can simply continue coding them in the Keywords area on subsequent F-spec lines.
No other File specification entries are required to describe the files the sample program uses. In this introductory explanation, we’ve skipped some of the entries that are not needed in this program (we’ll cover them later).
Definition specifications, identified by a D in position 6, follow the File specifications in the fixed-format example. D-specs define to your program those data items that do not originate as fields in a file’s record layout. In the example, Endofpage is one such data item. The following shows the general layout of the Definition specification as well as the example code:
This definition corresponds to the Dcl-s instruction in the earlier free-format example.
Data Item Name (Positions 7–21)
To define a standalone variable, you first name the variable anywhere in positions 7–21 (Name+++++++++++) of the line. The name need not begin in position 7. In fact, to aid readability, many programmers always leave position 7 blank to separate the data item name from the D in column 6.
Definition Type (Positions 24–25)
Definition specifications use positions 24–25 (Ds) to indicate the type of data item the line is defining. For a standalone variable, enter an S (for standalone) left-adjusted in these positions. In the free-format example earlier, the Dcl-s instruction serves the same purpose. Chapter 4 covers the other entries for other definition types.
Data Type (Position 40)
Position 40 (I) indicates what data type RPG uses to internally store a variable. For an indicator variable, enter an N (iNdicator) in position 40. Chapter 4 describes other possible entries for this position. Data type N corresponds to the Ind keyword used by the Dcl-s free-format instruction.
Keywords (Positions 44–80)
The Keywords area of the Definition specification provides an opportunity to further define the simple definition in positions 7–43. In this case, the example uses the Inz (Initialize) keyword to set Endofpage *On when the program starts.
In the fixed-format example, the program’s main procedure is written using Calculation specifications. C-specs are identified by a C in position 6. The following shows the general layout of Calculation specifications:
Notice that there are two general layouts. Most RPG operations use the first, traditional format (e.g., Factor 2, Result), and some use the second (Extended-Factor 2). You can freely intermix the two layouts. For the example, you need not be overly concerned about the differences between the two layouts; in fact, it may not even be obvious which operations are using which layout. The completed C-specs for the example program’s main procedure are as follows:
Let’s compare the fixed-format C-specs with the free-format main procedure shown earlier.
Operation Code (Positions 26–35)
Positions 26–35 (Opcode(E)++) contain the operation code, left-adjusted. In general, these are the same operation codes the free-format example used, although fixed-format C-specs also support several obsolete operation codes that are no longer commonly used. Notice that the operation code must begin in position 26. Fixed-format calculations do not allow indenting.
Factor 2 (Positions 36–49)
Many operation codes use operand values (factors) to provide the compiler with the details necessary to perform the operation. In the example, the following lines specify a Factor 2 operand, left-adjusted, in positions 36–49:
Some operation codes (though none in the example) also use a Factor 1 operand in positions 12–25 and a Result factor in positions 50–63.
Extended-Factor 2 (Positions 36–80)
Some operation codes, most notably Eval, support an Extended-Factor 2 in positions 36–80 as an alternative to the earlier shorter Factor 2. You can use the extended layout to code expressions instead of using simple operands. Operation codes that use the Extended-Factor 2 layout do not use Factor 1. In the example, these lines use the Extended-Factor 2:
Notice that the Eval operation, usually optional in free-format code, is required when you are using fixed-format C-specs.