IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators

It is hard to imagine an IBM midrange computer professional who is not at least acquainted with the language known as Report Program Generator, or RPG. This is because RPG is widespread among all members of the midrange computer family, beginning with IBM's System/3.

Overview

When IBM announced the System/3 in the late 1970s, it announced a second generation of RPG and aptly named it RPG II. This language was further refined with additional improvements when the System/34 was developed. The third generation of RPG came with the System/38 and included some relatively novel concepts, such as the ability to work with a fully integrated database.

The first AS/400 systems to ship were very much like the System/38, but with an improved user interface. The RPG III language that was developed for the System/38 was carried over to the AS/400 with very few changes, except for the name, which became RPG/400.

Even though there were initially few changes to RPG on the AS/400, the language continued to evolve. In 1994, IBM announced the long-awaited fourth generation of RPG and named it ILE RPG, but it is known more widely as RPG IV.

The Integrated Language Environment or ILE was an attempt by IBM to bring a variety of languages and environments together under a single framework. Although the concept was announced with V2R3 in the mid-1990s, the jury is still out on the overall success of the ILE concept. Such is not the case with RPG IV, however, because its success has been widely documented.

One very important aspect of ILE does apply to RPG IV, however: A series of RPG source statements that used to be compiled to make up a program are now compiled to make up a module instead. Modules of one or more languages may then be bound together to make up a program. A single series of RPG source statements may still be compiled to make up an RPG module, which may, in turn, be bound into a program. This methodology makes the ILE concept largely transparent to RPG programmers who were more familiar with the Original Program Model, which was used to describe the earlier version of RPG.

The success of RPG IV may be largely predicated on the many significant enhancements that were made to the language, many of which had existed in other programming languages for many years. Access to new data types, limited free-form expressions, new built-in functions (BIFs), and 10-character file and field names are just a few of the improvements that were made in the fourth generation of the RPG programming language. The 64-bit architecture of the AS/400 RISC systems had made many of the RPG language limitations and size constraints somewhat archaic, so RPG IV eliminated or largely increased many of the language-imposed limitations.

In spite of its humble beginnings (when RPG was used for creating report-type programs), RPG on the i5 is a full-fledged, high-level language that is capable of performing complex database operations, interactive applications that support subfiles, and heavy mass-update programs. Of course, RPG also creates report programs, thereby living up to its name.

The i5 supports five versions of RPG in V5R3. The System/36-compatible RPG II compiler creates native program objects from source code that was developed on or for a System/36 system. An RPG III compiler also is compatible with the AS/400's other predecessor, the System/38. The native RPG III compiler, often referred to as RPG/400, is much like the System/38 compiler, but with additional features. The native ILE RPG compiler, also known as RPG IV or ILE RPG/400, is the only host-based compiler that continues to be enhanced. Support for outdated versions of RPG shows IBM's commitment to customers by ensuring that they can continue to maintain their old but adequate programs without having to modify them.

The fifth version of RPG, Visual Age RPG, is based on RPG IV and runs on PCs. You can use VARPG to develop Windows-based client-server applications that access an i5 server.

IBM publishes several large volumes that explain RPG in great detail. If you need any information not provided in this chapter (which is just a presentation of the language, not a treatise on it), you should refer to IBM's manuals.

RPG Specifications

RPG IV is remarkably different from most other computer languages. While other languages are written on a blank sheet of paper, so to speak, RPG is largely columnar in nature and was originally hand-written onto preprinted forms (called coding sheets) where the programmer filled out the blanks with letters and numbers. The coding sheets were then given to a keypunch operator to prepare a deck of punched cards, ready to be submitted to the System/3 or System/360. Nowadays, no one would think of using coding sheets, but the "columnar" concept remains largely intact. However, exceptions do exist, as you will see.

An RPG module consists of a series of statements that are each generally one physical line long. The purpose of each statement is determined by the specification ID, which is a single letter located in column 6. The sequence of the specifications is important, and some of the specifications are optional. The pertinent specifications are those shown in Table 24.1.

The Structure of an RPG Module

As with many things in life, there is no single way to describe how you would construct all RPG IV program modules. Different ways are possible to construct the module because there are different reasons that it is required. But, the following model describes the way most of your RPG IV program modules will be constructed:

• H (header, also called control). A program can have multiple H-specs or none at all. If present, the H-specs must be the first statements in the program. The H-spec is free-form and the entries don't need to be entered in any particular order. The H-spec generally provides global options that apply to the entire module, such as a currency symbol or the default format of data types, such as time or date. The H-Spec can also be used to embed a copyright statement to include with a module.

• F (file, also called file definition). Each F-spec defines a single file to the module. The F-spec indicates the name of the file; whether it is opened for input, output, update, or combined I/O; and other file-level details. The first 43 characters of this specification are positional, while positions 44 through 80 are reserved for keywords that describe the file. If there is not enough room for all the file-related keywords, add an additional File Specification and leave positions 7 through 43 blank. The system will know that the keywords on the specification apply to the file name that directly precedes the statement.

• D (definition). D-specs are used to define arrays, tables, named constants, data structures, data structure subfields, tables, and variables that might consist of a wide variety of data types. Just as the File Specification, the Definition Specification is predicated on positional definition criteria for the first 43 characters, but positions 44 through 80 are reserved for definition keywords.

• I (input). I-specs are used when coding program-described files. Because files are usually defined external to programs through DDS, they are rarely used in RPG IV.

• C (calculation). The C-specs are generally considered to be the "meat and potatoes" of the RPG IV module. In C-specs, the action takes place. Each C-spec is an operation, such as reading a record, evaluating a logical decision, performing a subroutine call, or the like. The C-Spec has two options: fixed format and free-form. The fixed format C-Spec is columnar in nature, and its operands are all position-dependent. The free-form C-Spec is still fixed in positions 1 through 35, but the second part of the statement may be free-form depending on the operation code specified in positions 26 through 35.

• O (output). Like the I-specs, O-specs define output for program-described files.

• P (procedure boundaries). P-specs are used to define the boundaries of an RPG IV subprocedure. A subprocedure is a section of RPG IV code that has a name and specific purpose. Subprocedures modularize and standardize parts of an application.

Fixed Format

RPG IV is unique because, for the most part, it has a fixed format. You can't code your program statements anywhere you like. The RPG compiler forces you to utilize predefined spaces. If you do not use those spaces, the RPG compiler may not recognize your code as valid, or may misinterpret it.

For example, an F in column 18 of the F-specs means that the file is fullprocedural (an RPG term meaning that the file is manipulated manually using READ and WRITE operations). Shift that F four columns to the right (column 22) and its meaning changes. An F in column 22 means that the file is program described. An F in column 6 identifies the statement as a file specification.

Although it is true that the fixed format presents problems and limitations, it is also true that most business application programs can be coded in fixed format both quickly and efficiently. Efficiency is precisely why RPG has outlasted so many other programming languages through the years. RPG is designed and optimized for business. It was not designed to be all things for all programmers.

RPG Names

All RPG IV names must begin with a letter of the alphabet (A to Z) or the symbols @, #, or $. RPG IV names also can contain the underscore (_) character anywhere except the first position. The remaining characters can be more of the same or any of the 10 digits (0 to 9). All other symbols are invalid. All characters in a name may be written in uppercase, lowercase, or mixed case.

Indicators

RPG indicators are logical variables. An indicator can be either on (true) or off (false). Some indicators are pre-defined. You may define indicators of your own in the definition specifications.

Predefined RPG indicators are two-character codes:

• The 01–99 indicators are usually called general-purpose indicators. You can use them for anything, including communicating with display and printer files.

Other indicators have special functions:

• H1–H9 (halt indicators) are an obsolete feature that can be more trouble than they are worth. Do not use halt indicators in your program.

• KA–KN and KP–KY (function key indicators) can be used to sense when the user has pressed one of the function keys (F1 to F24) during the execution of an interactive program.

• L0–L9 (control level indicators) are used to detect changes in certain fields while the primary file is being processed record by record. You can use them to sense these changes and do things like print subtotals.

• LR (last record indicator) is used to signal the end of the execution of the program. If you have a primary file, LR turns on when the last record is read. You can also turn it on manually.

• MR (matching record indicator) is used when processing a primary and a secondary file using the matching record technique. MR turns on when the corresponding fields in the two files have the same values.

• OA–OG and OV (overflow indicators) are used to sense the end of a physical page while writing to a printer file. You can use these indicators to control skipping to a new page and printing headings.

• 1P (first page indicator) is on only at the beginning of the program, when the printer file is at the first page. You can use it, for example, to print different information on the first page.

The current tendency among programmers is to avoid the use of predefined indicators whenever possible, but using such indicators can be advantageous in some circumstances. For example, you can use indicators to control the attributes of fields in an interactive program's display file.

The RPG Cycle

RPG provides a built-in processing cycle. Because most business application programs must perform input, calculations, and output, the RPG compiler provides this process automatically in the RPG cycle. This cycle is not unlike the built-in logic of widely used UNIX utilities, such as grep, sed, awk, and Perl.

A file can be designated as the "Primary Input." When you use a primary file, the RPG cycle automatically reads it, performs the calculations coded in the C-specs, and then performs whatever output you indicate (to itself, if the file is being updated, or to a different file such as a printer file).

In addition, the RPG cycle offers other effort-saving features. You can code control-level breaks by using L1–L9 indicators on the I-specs that define certain fields of the primary file. When the system reads a record (automatically, because you are using the cycle), and it detects that those fields have changed, it turns on the indicator. You can use that indicator to command the program to print subtotals or to perform other operations.

Even if you do not use a primary file, the cycle is still active, and you must indicate to the program when to end by turning on the LR indicator.