|Publisher:||MC Press, LLC|
|Sold by:||Barnes & Noble|
|File size:||5 MB|
About the Author
Read an Excerpt
Free-Format RPG IV
By Jim Martin
MC PressCopyright © 2013 Jim Martin
All rights reserved.
Pre-Free-Format RPG IV
The RPG programming language has certainly come a long way since its introduction as a simple report program generator in the 1960s. From the earliest versions of RPG to the latest release of free-format RPG IV on the IBM® Power® platform, the changes have been dramatic.
The centerpiece of today's RPG is its support for a free-format style of calculation coding. Free format puts RPG on the map of modern programming languages and gives programmers important new functionality for constructing programs that are easier to create, understand, and maintain. If you are writing RPG programs today, you owe it to yourself to make the most of this great new function.
In this book, you will learn the ins and outs of free-format RPG, from I/O and program flow to data manipulation, math operations, and call and return. But before we dive into the delights of free-format RPG, let's take a brief look at its precursor: fixed-format RPG IV.
Even before free format, RPG IV was a powerful, functionally rich programming language. RPG IV — or ILE RPG, as it is officially known — debuted in late 1994 with Version 3 Release 1 (V3R1) of the OS/400® operating system. IBM had introduced the Integrated Language Environment (ILE) in a prior release, but everyone eagerly awaited RPG's entrée into ILE. Three major additions to RPG in V3R1 brought the language a significant level of sophistication that was absent before: the extended Factor 2, built-in functions, and subprocedures.
Extended Factor 2
The introduction of the extended Factor 2 format, along with operations to exploit it, represented a huge departure from RPG's past. With this enhancement to calculation specifications, RPG programmers could now use operations such as Eval (Evaluate expression) and If (If) with long expressions.
The ability to use math symbols (+, -, *, /) within expressions was a major step in modernizing the language. Other symbols, used in comparison expressions, included equal (=), less than (<), greater than (>), less than or equal (<=), greater than or equal (>=), and not equal (<>). The exponentiation symbol (**) became the newest math operator, and support for parentheses let programmers indicate higher precedence in math or comparison expressions. Other programming languages had used these symbols for a while, and IBM chose to bring them into its new version of RPG.
One of the symbols, the plus operator (+), also found another use in RPG IV: concatenation. Using this new operator, programmers could put character data together into strings much more easily than with previous methods.
IBM System i® programmers were already familiar with built-in functions through their use of such functions in Control Language (CL). The %Sst (Substring) and %Bin (Binary) functions, for example, are commonly used CL built-in functions.
The whole idea of an RPG IV built-in function was based on the C language function idea. A built-in function performs one task, with or without parameters, and usually returns data of a predetermined data type to the point in the program where the function was specified. For example, RPG IV's %Eof (End-of-file) built-in function checks for end of file after a Read operation, eliminating the need to code a resulting indicator on the Read. The %Found (Return found condition) built-in function lets you check for a record-found condition after a Chain operation without using a resulting indicator.
The number of built-in functions available in RPG, as of V7.1, has grown from the dozen or so in RPG IV's initial release to 80 now. Many of these built in functions duplicate the function of older operation codes, such as Scan (built-in function %Scan) and Subst (built-in function %Subst). In some cases, the built-in function provides more capabilities than the operation code it replaces. The %Subst (Get substring) built-in function, for example, can substring a target string as well as a source string, whereas the Subst operation code can substring only a source string.
As if these new capabilities weren't enough, IBM added another big feature to RPG IV. Subprocedures give RPG IV programmers the option to break complex programs into smaller parts and to create "home-grown" built-in functions if desired. For the first time in RPG, the concept of a "local" variable was introduced for use in subprocedures. Also for the first time, a routine — in this case, a subprocedure — was able to use recursion.
In RPG IV, IBM also eliminated many of the old constraints of RPG/400® (RPG IV's predecessor). Eight-character file and record names were lengthened to 10. Field names were lengthened, too — at first to 10 and then to 4,096! The max-imum size of character fields was enlarged from 256 bytes to 16 megabytes! Packed numeric field length size was raised to 30 and then 31 digits; it now stands at 63.
Even fans of binary and hexadecimal programming were given something new in RPG IV. Previously, you could convert two-byte binary numbers to four-digit decimal numbers and convert four-byte binary numbers to nine digits. The new RPG IV language provided an integer data type, both signed and unsigned, up to 20 digits. To handle ultra-small and ultra-large numbers, the floating-point data type made its debut, in both standard and double precision.
Other data types added to the language include the pointer data type, which contains the address of data or a procedure; the date, time, and timestamp data types; and the object data type, used to handle references to a Java® object.
Adding these new data types and enlarging the older ones must have come from some larger motivating factor. Why did IBM provide all these things? In my opinion, the reasons lie in maintaining the Power system as a modern and viable solution for the midrange server marketplace. Older RPG can easily be called a "dinosaur" in this modern age. The gap in programming capabilities between older RPG and modern languages such as C, C++, Java, and others is huge. With today's RPG IV, there is no gap. RPG IV has "come from behind" to be a major player in the modern world of application development.
Some "Baggage" That Came Along
Like any responsible vendor, IBM doesn't like to offend any of its customers. If you wrote an RPG program in 1969 that used the RPG cycle and 99 indicators, IBM won't tell you that your approach is obsolete. Instead, IBM continues to provide a compatibility path from the "here and now" back to almost any previous time in RPG's history. The machines may change every six to eight years, but programs and the inherent investment made in developing them are preserved. One byproduct of this commitment to long-time customers and their legacy code is that RPG IV, in its current form, carries the weight of 40 years of "baggage." The RPG cycle, and its emulation of 1960s accounting machines, lives on.
When IBM introduced RPG IV, many of us hoped we might see a break with the past. Companies that cared little about change could stay with RPG/400, and those interested in new ideas could embrace the new incarnation of RPG. Maybe, I thought, the new RPG would at least drop the cycle. Perhaps we'd be able to use only newer instructions such as Eval, with oldies like Add, Sub, Mult, and Div relegated to the history books. Maybe calculation "definitions" would be eliminated in light of the new definition specifications. But, no, we got all the older operations and functions along with the new. Today's RPG IV truly is a huge collage of language functionality, encompassing both old and new functions!
New programs don't have to use the old operation codes, primary files, or variables defined in calculations. All this is true. But did you know that a kernel of the RPG cycle code is a part of every RPG IV program, even if you didn't specified a primary file? How else could the LR and RT indicators do their jobs?
In the next chapter, I explain why I believe that the free-format style is a better alternative to coding RPG IV. In fact, I will go so far as to say that this new style is necessary for the future of this programming language. Later, in Chapter 3, I introduce you to free-format RPG IV. Subsequent chapters delve into the details and provide plenty of examples to demonstrate the features of the language. Here's a preview of some of the good news: In a major break with the past, most of the original-format operations aren't available in free-format RPG.
Modern programmers see the free-format style as RPG's newfound strength. There will always be some who will criticize IBM for omitting a preferred language function in free format. Regardless, free-format RPG IV is a great, modern programming language!CHAPTER 2
The Case for Free-Format RPG
We in the RPG community can gain important advantages by adopting the free-format style of coding. There will always be RPG programmers who prefer to code using the fixed-format method, and that is fine. My goal in writing this chapter is to describe some of the benefits to be reaped if you embrace the freeformat style.
Easier to Read and Maintain
The greatest advantage that free-format RPG IV offers you as a programmer is that it lets you write code that is easier to read and maintain. The great majority of RPG IV programmers today are maintenance programmers. As a maintenance programmer, you inherit programs written by someone else. If a program is written well, with lots of comments and a clear structure, the job of fixing or changing it isn't too bad. The quality of the original program, more than your own abilities, is what determines productivity.
A program that is easier to read is easier to maintain. What makes a program "easier to read?" That's an interesting question, which I will now try to answer.
A program is easier to read if the author of the program observed the following practices:
Good field naming
Use of comments
No Goto operations
Free-format RPG IV offers us an opportunity to implement each of these programming practices.
Good Field Naming
The six-character field names of RPG/400 are over. Fixed or free, we in RPG IV can now use longer names, and we should. Granted, DDS still restricts us to 10-character names, but that is not nearly as bad as six.
The problem with short names is that they force us to be cryptic, and "cryptic" is the antithesis of good field naming. The name-length limit is now huge at 4,096 positions, enabling us to create names that aid the reader in understanding what is happening in a program. Names that are too long can be just as miserable as names that are too short, so I suggest a happy middle ground around 10 to 15 characters long.
In addition to having an appropriate length, field names should be meaningful. That's easier said than done, I know, but we must try. Which of these two field names is more meaningful: TOTAL or Month_Sales_Total?
The principles of good field naming apply to indicators, too. In RPG IV, we can name our indicators. In fact, an unlimited number of named indicators are available to us. The jury is in on numbered indicators. They are cryptic and no longer necessary in RPG IV, for any reason. If you saw the following code in an RPG program that you had been assigned to maintain, what would you need to do first?
You would need to find out what *IN67 means! To determine where this indicator was used and changed, you would need to use the compiler cross-reference.
By their very nature, numbered indicators are cryptic. It takes time to unravel their meaning. In larger programs, an indicator may serve more than one purpose. Decrypting these situations takes even more time.
Naming indicators isn't a new idea. Named fields defined as Boolean (e.g., *LGL in CL) have been around for decades in other programming languages. What if we substituted a well-named named indicator in the preceding code example?
For a maintenance programmer, it is far more productive to make program changes or fixes when the program uses indicators like this one. As with field names, choosing a good name for the indicator is important. Names such as Flag_1, Flag_2, and so on are no better than *IN67.
For indicators associated with externally described files, use the named indicator data structure, with file description keyword INDDS. You also must specify file-level keyword INDARA on the external file's DDS to permit this feature to be compiled properly. If an indicator in a display file has two meanings, depending on which record format is being used, just create two entries for the same indicator in the data structure. Even the overflow indicator associated with external printer files can be a standalone named indicator.
The availability of longer names helps us make programs easier to read. Using such names in fixed format's extended Factor 2 area is fine, but the available space is limited to positions 36-80, or 45 locations. In free format, the line space available for an operation and its parameters is positions 8-80, or 73 locations. Even allowing for an operation code, that gives you approximately 50 percent more room to enter field names and expression operators.
Long expressions that include longer names will look "crowded" in the extended Factor 2 format. Free format eliminates (to some extent) this problem.
When you indent your code, you give readers of your program visual cues about your intent as the program's author. We use indenting in data structures to clarify for the reader what the data structure subfields are. We do the same thing for parameters in prototypes and procedure interface definitions.
Indenting calculations wasn't possible in RPG until free format became available. A common practice for maintenance programmers faced with a complex nesting of If and Do groups has been to print out the complex section, tape the pages together (if not using continuous forms), and then use a ruler and pen to "bracket" the Ifs and Dos. The purpose of this bracketing is to provide a visual aid in understanding the logic. I've certainly performed this exercise many times.
In free-format RPG IV, you can indent statements that lie within an If or Do block. By indenting, you create a visual aid to help the maintenance programmers who will come later understand the program logic better. Other free-format languages, including C, Cobol, Pascal, PL/1, and others, have used this approach for years. Indenting, like good field naming, helps make programs easier to read and maintain.
Use of Comments
Any program is easier to understand and maintain if the program author chooses to use comments. Including comments in your programs takes a bit of extra time when coding, but it yields a big savings in time for the maintenance programmer. It is naive to assume that maintenance programmers can read and understand others' programs quickly, especially very large programs. Having plenty of good comments really helps.
"How much should I comment?" I hear this question all the time, and I have a stock response: "As much as you have time for." An investment in comments yields a great reward later on.
In fixed-format RPG IV, you can specify comments almost anywhere in a program by placing an asterisk (*) in position 7. The entire line is then considered a comment. On a calculation line, comments are permitted in positions 81-100. If you are using a traditional 24x80 display, you cannot see these "end-line" comments unless you either scroll to the right or use the alternate display format, which shows 27 lines and 132 columns. I am not a big fan of the alternate display format because the screen data then becomes very small and harder to see.
In free-format RPG IV, you can enter a comment on any line by preceding it with two forward slashes (//). The slashes can begin in position 8 to provide a complete line of comment. Comments can also appear at the end of a line of source code. Free-format specifications end in position 80, so all comments are viewable using the traditional 24x80 display. In free-format RPG, you may continue comments up to position 100; however, if you do so, you run the risk of their not being seen or updated when changes are made in the code.
Excerpted from Free-Format RPG IV by Jim Martin. Copyright © 2013 Jim Martin. 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.
Table of Contents
ContentsPreface to the Second Edition,
A Note About Source Entry,
Chapter 1: Pre-Free-Format RPG IV,
Chapter 2: The Case for Free-Format RPG,
Chapter 3: Introducing Free-Format RPG IV,
Chapter 4: Input/Output Using Free Format,
Chapter 5: Program Flow Using Free Format,
Chapter 6: Embedded SQL Operations Using Free Format,
Chapter 7: Data-Manipulation Operations Using Free Format,
Chapter 8: Math Operations in Free Format,
Chapter 9: Call and Return in Free Format,
Chapter 10: Solutions for Problem Situations,
Chapter 11: Sample Programs,
Appendix A: Free-Format Operations,
Appendix B: Example Screens, DDS, and Programs,
Appendix C: Free-Format Alternatives for Fixed-Format Operations,