RPG IV is nearly 10 years old. Most modern technologies take about 10 years to be introduced into the public at large. RPG IV is no different; for 10 years, many of us have been trying to persuade RPG III programmers to make the move, but it has been a difficult road. Today, the floodgates are open, and it is rare that you go into an iSeries shop without seeing at least some level of RPG IV being used.
Originally, RPG IV was just a replacement for RPG III, with most of the language's limitations either removed or improved to a point of being virtually removed. For example, the length of a field was increased from 256 characters to 32,767 and later (around V4R4) increased again to 65,535.
IBM improved upon the language's capabilities with seemingly every release. Take the length of a numeric field. RPG III was limited to 15 with 9 decimals. RPG IV increased that to 30 with 30 decimals. Then, in V5R2, it increased to 31 with 31 decimals, and in V5R3 it increased again, to 63 with 63 decimals. Why couldn't IBM have just waited and jumped right to 63?
One interesting enhancement in RPG IV over RPG III was the length of a field name. In RPG III, a 6-character field name was the limit. RPG IV introduced 10-character field names, and everyone thought, "Wow! How could I ever use that many characters for a field name?"
Then, in V3R7, IBM did something very interesting. Partly in response to critics and partly simply because it was possible, IBM increased the number of characters we could use in a field name to 4096. While field name lengths could have simply been unlimited, IBM chose to document the limitation. That way, if somebody actually tried to hit the limit, they could ask, "What's wrong with you?"
So RPG went from having what some consider the shortest limitation for field names to the longest. Even the C language, which boasts 255 or so characters for field names, only truly recognizes the first 16 unique characters, ignoring the rest. RPG IV is truly the champ in this area.
Probably the single biggest and most important enhancement to RPG IV over RPG III was the introduction of subprocedures. Yet that enhancement is probably one of the least-used new features. Oh sure, regular readers of this column use subprocedures at some level, but the vast majority of RPG IV programmers still haven't written that first subprocedure. Perhaps one problem is that IBM called them "subprocedures" instead of "procedures." This gives them a false association with subroutines. While this was intended to bring subroutine writers over to subprocedures more easily, what has happened is that programmers feel that the two are so similar that there is little reason to move off of subroutines.
You see this every day when you look at someone's /free code that includes subroutines all over the place. Is that irony or what?
Another major new feature was the controversial /free syntax. This feature allows RPG programmers to avoid using most of the fixed-format columns. I say "most" because you still cannot code anything in columns 6 or 7; consequently, you have to specify free-format code in columns 8 though 80.
There is still plenty of room for improvement in the /free syntax, including the fact that there is no compelling reason to require /free and /end-free statements. If nothing is in 6 and 7, then it should be considered a free-format statement. In fact, IBM already does this with comments. If you specify two slashes (//) as the first characters on the line, IBM interprets them as /free comments, even when they are intermixed with fixed-format code. Here's an example:
C if NOT %EOF()
// Test for all numeric
C if %Check('0123456789':CSTNBR) = 0
C callp GetCustData(CSTNBR)
C endif
C endif
The third line is considered a comment by the compiler. So why doesn't this compile?
C if NOT %EOF()
chain (CstNbr:Region:ItmNbr) OrdHist;
C endif
Granted, I don't care for this specific example, but you get the point.
Another major enhancement was the introduction of the FOR opcode. This opcode replaces the legacy DO opcode by allowing you to specify an expression in Extended Factor 2 or free-format. Here's an example:
C eval var = MyArr(i)
C if %Check('0123456789':MyArr(I)) = 1
C Leave
C endif
C endfor
The FOR opcode allows you to specify a variable that is automatically incremented each time the loop is performed (similar to a DO loop) as well as a loop limit and an increment value. By allowing expressions, you can do things that allow you to avoid unnecessary work fields, as illustrated in this example, %ELEM(MYARR).
Of the other new operation codes, the EVALR (copy text, right-justified) is probably the most significant. This opcode allows you to simply and easily copy one character value to another with right-justification. Interestingly, I often have to point out that it "only" works with character variables since EVAL implicitly copies numeric data right-justified. I suppose people think that EVALR should work with numeric values, and perhaps it could, but EVAL already does a fine job of that.
Originally, IBM planned a complicated set of built-in functions that required you to wrap your variables in these built-in functions and then use other built-in functions (nested built-ins) to end up with right-justified text. I mentioned to them that perhaps something easier was better and recommended EVALR. Fortunately, IBM decided to use EVALR, and it's been a great success; you now only need to specify EVALR target = source and the data is copied beginning on the right side of the variables. In fact, IBM did such a good job of "componentizing" the EVALR functionality that they added it to procedure parameters. You can specify an OPTIONS(*RIGHTADJ) value for a procedure, and the compiler effectively issues an EVALR operation on the data specified for the parameter. The only problem is that some people think EVALR is one of those V5R2 or later features. Little do they know it has been around for a long time.
Finally, what conversation about RPG IV history would be complete without mentioning built-in functions? Built-in functions (a.k.a. "built-ins" or BIFs) opened up a level of flexibility in programming RPG IV beyond anything else IBM has done to the language, save subprocedures. The original list of built-in functions included the following:
- %ELEM
- %SIZE
- %TRIMx
- %SUBST
- %ADDR
- %PADDR
Today, there are over 100 built-in functions and while I would have to do a count to verify it, I believe there are now more built-in functions than operation codes. At one point, IBM decided that no more opcodes would be created; only built-ins would be introduced. But that philosophy has changed, and now new opcodes and built-in functions are being created. I have a page on my Web site that includes documentation (including release availability) for all built-in functions. I haven't updated it for V5R3 as of this writing, but it is fairly complete.
RPG IV has come a long way since OS/400 V3R1. It has grown from being a simple replacement for RPG III syntax to the powerful language it is today. It can compete with virtually every other language out there on features and flexibility. While there is always room for improvement in areas of consistency and performance, RPG IV has truly become The Modern RPG Language.
Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.
LATEST COMMENTS
MC Press Online