Read an Excerpt

Programming in RPG IV

MC Press

Introduction to Programming and RPG

Chapter Overview

This chapter introduces you to RPG and describes its history and evolution from punched cards to a modern business programming language. It also explains general programming and computer-related concepts that you need to know as you begin to program in RPG IV.

Programming

Computer programming involves writing instructions that tell a computer exactly how to process, or manipulate, data. No matter how complex a computer application may be, its actions are ultimately directed by individual lines of code that operate on input information and generate a result. When those individual instructions are organized and grouped together, they typically represent a step-by-step process that will result in a specific product, such as a sales report. It is the job of a computer programmer to design, organize, write, and test those individual lines of code, creating a working computer program as the end result.

The computer is a binary device, with electronic components that can depict only two states: on and off, or flow of current and no flow of current. To represent those states, computers internally store and manipulate instructions (and data) as patterns of bits, or binary digits, with values of 1 or 0. Programmers originally were forced to write computer instructions as strings of 1s and 0s, using machine language. Humans, however, do not function as well at this low-representation level. Fortunately, advances in computer science soon led to the development of high-level languages (HLLs).

A high-level language allows a programmer to write computer instructions in a format and syntax that is more easily recognizable than long strings of 1s and 0s. This HLL source code is stored in a file on the computer. But before the computer can actually execute the instructions, they must be translated into the bit patterns that the computer can recognize. The computer itself can accomplish this translation using a special program called a compiler. A compiler reads the source code and translates it into machine language that the computer can understand.

History of RPG

IBM introduced the Report Program Generator (RPG) programming language in the early 1960s. RPG was one of the first high-level languages. It filled a niche for providing quick solutions to a common business task: generating reports needed within the business. RPG was unique among computer languages in several respects.

RPG is a procedural language. Procedural languages typically require that you explicitly code each processing step or instruction, in the correct sequence, to define the procedure or process necessary for the computer to produce the end result. Unlike other procedural languages, RPG did not require the programmer to detail each processing step. Instead, the language included a fixed logic cycle that automatically executed the normal read–calculate–write process found in most report programs.

The RPG programmer's job was to describe accurately the files, record layouts, calculations, and output desired for a specific program. RPG required that these descriptive specifications appear in a specific designated sequence within a program and that entries within each specification line appear in fixed locations, or columns. The programmer typically coded these specifications onto paper hole-punch cards, a deck of which formed the source code for a program. The RPG compiler read that card deck and, through its logic cycle, supplied the needed missing steps to provide a standard machine language program for the computer to execute.

Another unique characteristic of RPG was its use of a special class of built-in variables called indicators. These variables, many of which simply had numbers for names, were predefined to the computer and could have only one of two values: '1' or '0' (corresponding to "on" or "off"). The indicators could be set on or off in one part of the program; their status could then be referenced in another part of the program to determine what processing was to occur.

RPG II

By the late 1960s, RPG had gained popularity, especially in small and midsized data-processing departments. Programmers were stretching the language beyond its original intended use and using RPG for complex computations and complicated file updating as well as for report generation.

Accordingly, IBM introduced an enhanced version of the language — RPG II — when it released its System/3 computer. Other computer vendors observed the popularity of RPG and developed RPG II compilers for their minicomputers — but for the most part, RPG remained a language associated with IBM installations.

RPG III

During the 1970s, several trends in data processing became apparent. First, as computers became less expensive and more powerful and as operating systems became more sophisticated, interest in interactive programs began to mushroom. In interactive applications, a user interacts directly with the computer through a terminal or workstation to control the actions of a computer program as it is running. Previously, programs had involved only batch processing, in which the computer processes a "batch" of data (typically representing business transactions) without user intervention.

A second emerging trend was a growing interest in a database approach to data management. With a database approach, programmers define data independently of programs, using a database design tool, such as Structured Query Language (SQL). The files storing the data are rigorously designed and organized to minimize redundancy and to facilitate accessing data stored in separate files. Any program can use these database files without having to explicitly define the details of the data within the program itself.

Finally, a third trend during that decade was an increasing concern with program design. This trend resulted in a methodology called structured design. As companies' libraries of developed programs continued to grow, the need to revise those programs to fit evolving business needs grew as well. It became apparent that computer professionals had paid too little attention to the initial design of programs. Poorly designed programs were causing inefficiencies in program maintenance. Experts attributed much of this inefficiency to "spaghetti code" — that is, to programs that included undisciplined, haphazard transfer of control from one part of a program to another.

Advocates of structured design recommended restricting indiscriminate flow of control within a program and using only those operations that kept tight controls on that flow. With this emphasis on structured design, concepts of modular programming and code reusability also began to emerge.

IBM addressed all these trends when it introduced the System/38 minicomputer in 1979. This computer's architecture was unique in that the design of the computer and its operating system featured a built-in database, and the S/38 required data files to be predefined at a system level before a program could reference or use those files. This requirement alone forced IBM to release a new version of RPG to allow external file definition. IBM called this new version RPG III.

At this time, IBM also made several other major changes to RPG. First, it added features that made it easier for programmers to develop interactive applications. Second, to address the issues of structured design, IBM included structured operations for looping and decision logic. Finally, to support modular code and reusability, IBM revamped the language to include the capability to perform calls to other programs and to pass data between programs.

RPG/400

In 1988, IBM announced its successor computer to the S/38: the Application System/400, or AS/400. With the new computer came a new version of RPG: RPG/400.

Despite its new name, RPG/400 was really just a compiler that read the existing RPG III syntax and had a few added operations and enhancements. Following RPG/400's initial release, IBM periodically added additional features to the language, but these changes, too, were relatively minor.

RPG IV

Meanwhile, a growing number of critics accused that RPG was difficult to understand because of its short data names, abbreviated operation codes, and rigidly fixed format. The critics contended that the language was showing its age in its limited choice of data types (e.g., no direct support for date data types), its inability to handle multidimensional arrays, and its patchwork approach to data definition.

To address some of these criticisms, in 1994, concurrent with the release of V3R1 of the AS/400's operating system (called OS/400), IBM introduced a version of RPG sufficiently unlike earlier versions that it warranted a change in name: RPG IV. In addition to trying to address the criticisms previously mentioned, IBM included RPG as part of its newly introduced Integrated Language Environment (ILE), a programming model that allows program modules to be first compiled and then bound together into executable programs. This change supported the growing interest in developing reusable units of code and improving system performance. Moreover, it let programmers develop a program using modules written in different computer languages and then bind these modules into a single program.

RPG IV (also commonly known as ILE RPG/400) relaxes many of the strict fixed-format requirements imposed by previous RPG versions, allowing free-format expressions and keyword notation in its specifications. Data naming limits have been extended, and many other artificial limits have been effectively removed from the language. In addition, RPG IV adds several new organizational constructs, including a central data definition specification and procedure prototyping, which lets many program modules efficiently share information with each other. RPG IV borrows many of the best features of other programming languages and incorporates those features into its own new syntax.

IBM has rebranded the AS/400 several times over its lifetime to conform to current marketing strategies. It has been known by various combinations of AS/400, eServer, iSeries, and System i. The OS/400 operating system has also been rebranded as i5/OS, which is the name we will use in this text. Despite the system's various names, though, the RPG IV syntax remains intact.

Recent releases of RPG IV have focused on enabling the RPG IV architecture to coexist with Internet-based applications and objected-oriented languages, including Java. Modern e-business applications usually incorporate several hardware platforms (most notably, Intel-based computers) and software standards. As RPG IV evolves, it strives to maintain compatibility with these platforms and standards.

These changes have quieted — but not suppressed — RPG's critics. However, given the large base of existing RPG applications and IBM's present willingness to support RPG, it is likely that the language will continue to evolve and will remain the primary language for application development on i5/OS for many years to come.

If you compared RPG programs written 20 years ago with those written by RPG professionals today, you would be struck by their great design differences. These differences are not due solely to the use of operations unavailable in the past, although the new operations enabled the changes. The biggest change is that RPG, originally a language that emphasized specification instead of procedure, has been transformed by programming practices into a largely free-format procedural language. Today's programmers virtually ignore RPG's fixed logic cycle — the feature that made the language unique in the 1960s. And most modern programmers use RPG's indicators only in those instances in which the language absolutely requires their use.

Learning the RPG Language

Many RPG texts start by instructing students in RPG II and introduce RPG III or RPG IV only after thoroughly indoctrinating the students in the fixed logic cycle and the use of indicators. This book begins by teaching RPG as today's programmers use it. Only after you have mastered modern RPG will you become familiar with features of the language that were common in the past.

You may wonder why (if RPG programming has changed so much) you, as a student, even need to bother to learn features of the older versions of RPG. The reason is simple: For better or worse, most companies still use some programs that were written ten or more years ago. Because your first job in the computer profession probably will involve maintenance programming, you no doubt will be working with some programs based on RPG III or even RPG II. You will therefore need to understand the features of these language versions so that you can modify such programs when you encounter them. Appendix E points out the important differences between RPG II, RPG III, and RPG IV that you will need to know to complete your understanding of this language.

The newest releases of the RPG IV compiler allow free-format specifications for certain portions of the program. Free-format specifications bring with them many advantages, including improved readability, improved reliability, the ability to indent code, and a similarity to other languages you may already know. In this book, you'll generally find free-format illustrations. Because free format is a relatively new feature of RPG IV, however, it's likely that you will encounter many older fixed-format RPG IV programs. Appendix E describes fixed-format syntax. While the free-format version is generally preferred, your organization's standards will dictate which alternative you will use.

Now that you have an understanding of RPG's evolution, we can turn to some basic programming concepts that you need to know before you begin to learn RPG IV programming.

Note

Though this book refers to the System i hardware throughout, most RPG IV concepts also apply to older AS/400 and iSeries hardware. The i5/OS operating system concepts also apply to the operating system under its old name, OS/400.

Program Variables

Computer programs would be of little value if you needed a different program each time you wanted to change the values of the data to be processed. For example, imagine you are developing a payroll program, and one processing step is to multiply hours worked by pay rate. If you had to rewrite this step to explicitly state the number of hours worked and the hourly pay rate for each employee, you would be better off calculating wages by hand or with a calculator. The power and value of computer programming rests in the concept of variables.

A program variable is a named data item within a program that represents a location in the memory of the computer that can store data. When a programming instruction involves the manipulation of a variable, the computer checks the value stored at that memory location and uses that value in the calculation. Thus, you can tell the computer to take the value stored in variable Hours, multiply that by the value stored in variable Rate, and store the answer in variable GrossPay. If Hours contained 35 and Rate 6, GrossPay would become 210. If Hours contained 40 and Rate 5, GrossPay would become 200. In a program you might represent this process using variable names in this expression:

GrossPay = Hours * Rate;

RPG has traditionally used the term field rather than variable. Modern usage tends to restrict the term field to those variables defined within a database file and uses variable for other data items defined in the program; however, the terms are generally interchangeable. RPG is a strictly typed language — it requires you to define all variables by naming them, assigning each one a fixed length that determines the amount of memory allocated for storing the variable's values and declaring what type of data (character, numeric, date, etc.) the variable will contain. A program variable's name has meaning only within the context of the program where it is defined, even if it is a field in a database file. You will learn the methods RPG IV uses to define variables and the data types it allows in subsequent chapters of this book.

---

Excerpted from Programming in RPG IV by Bryan Meyers, Jim Buck. Copyright © 2010 Brian Meyers and Jim Buck. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---