A Brief History of RPG IV

After the initial “explosion” of new functionality that arrived with RPG IV, RPGers were hopeful that the momentum would be maintained and that RPG would continue to add new functionality. They weren't disappointed. In fact RPG IV has added more new functionality with each release than RPG/400 did in its lifetime. Let's just take a trip back through the release highlights:

V3R2/V3R6 bought what has to have been the biggest change ever in RPG’s history. Subprocedures complete with local variables. Along with subprocedure support came the ability to prototype all kinds of calls. That support also allowed C functions to be used from RPG for the first time—the doors to the IFS, Web programming and more were thrown open.

V3R7 brought further enhancements to our ability to interact with C functions with the addition of null terminated string support and the ability to define floating point variables. In addition a whole new slew of built-in functions were added, most notable of these being %EDITC, %EDITW and %SCAN.

Next came V4R2 and what a release that was! The introduction of the INDDS keyword for F-specs gave those of us who had a passionate dislike for numbered indicators a new way to avoid them and at long last give meaningful names to those pesky little devils. And that wasn’t the end of the indicator goodies! Along came %EOF, %FOUND and friends to save us from those nasty resulting indicators on I/O operations. Variable length field support was also added in this release, although we didn’t really begin to appreciate how useful it was until we started doing more Web and IFS work and found how much more efficient it made string building operations.

V4R4 didn’t have any obvious big hitter, but did introduce the FOR loop op-code that we now use in just about every program we write. With the addition of the UCS-2 (Unicode) data type the foundations were also laid for fully enabling multilingual support in RPG.

And then along came V5R1. In many people’s minds, this represented an even bigger leap than V3R2 with the introduction of /Free-form RPG with all of the accompanying new built-ins. Needless to say, the introduction of free-form RPG was controversial in some quarters but we’ve always been big fans and have seen no reason to change our minds. From time to time, we’re still forced to code in fixed form when updating an old program, but whenever practical we convert such programs to /Free and work from there. /Free would have been a big enough change by itself but this release also added support for calling Java methods from RPG, thereby opening up a whole new world of free software. This release also added the capability to have multiple fields with the same name by allowing a DS to be QUALIFIED. The real utility value of this support was not to be fully realized until V5R2 arrived and RPG’s data definition support finally “grew up.”

There were so many changes in V5R2 that it’s difficult to pick a favorite, but certainly LIKEDS (and the companion LIKEREC) keywords for DS definition had a profound effect on the way we program. The capability to code data structure arrays (replacing the blunt instrument of Multiple Occurrence DS) was long overdue, and since data structures can contain arrays we finally had two dimensional arrays available to us. If you don’t understand why that was such a critical need, just think spreadsheets. Before the advent of two-dimensional arrays, you could not code the equivalent of a simple spreadsheet in RPG—not without performing unnatural acts, anyway!

Beyond the data definition changes V5R2 also brought significant updates in the area of I/O, most notably the capability to do away with antiquated KLISTs. Now we directly specify the keys we want on the op-code itself. And even if you felt there was some advantage to the KLIST style of coding, the new %KDS BIF provided a simpler, cleaner approach to building the list. Jon’s personal favorites in this area were: the capability on the UPDATE op-code to specify the fields to be updated (he had suffered many lengthy debug sessions caused by programmers who didn’t realize that ALL fields were updated by the original version) and the capability to use FEOD to secure updates without incurring the overhead of waiting while the date was written to disk.

V5R3 was not such a showstopper as the previous two releases—the compiler writers needed to take a breather at some time! Nevertheless the enhancements were still welcome, particularly the capability of %TRIM and friends to specify the characters to be trimmed. Also added was %SUBARR which at long last allowed us to avoid filling unused array entries with high values (for example) in order to get searches and sorts to work properly. One other significant change was the capability to specify numeric fields as being up to 63 digits in length—apparently the compiler team was aware of the potential for large increases in the size of the national debt and wanted to ensure that RPG could take its place in ensuring that it was calculated correctly!

V5R4 brought XML support! XML-INTO and XML-SAX while perhaps missing some functionality (subsequently addressed in V7 and PTFed into V6) this was a major step and, if nothing else, brought many RPGers to the realization that XML was going to play an ever-increasing role in their lives. The other biggie in this release was the introduction of EVAL-CORR (Eval Corresponding). All the time that RPG only allowed a one-name-one-variable approach to data definition, programmers accepted that they would have to move data from one place to another a field at a time. With the capability to use the same field name but differentiate via the name of the DS in which the field was defined, it was important to have a simpler option. EVAL-CORR supplied that and has been part of our coding arsenal ever since.

V6 was another game changer. If there was one thing that V5R2’s nested data structures and V5R4’s XML-INTO taught us it was that 64K just wasn’t big enough! 64K was the limit for a single field, and therefore the limit for any one element of a DS. V6 upped the limits for everything and we now have 16Mb as the upper limit—for fields, arrays, DS, everything. As if that wasn’t enough, we also got the capability to define local files in subprocedures and to pass files as parameter—something that is well worth exploring for those of you who have yet to try it. Our other personal favorite was the TEMPLATE keyword. Now we can define our own data types and include them in a /COPY member so that any time we need an address, a phone number, part number, etc., we can simply use LIKEDS to include that structure. Of course, we have effectively done this in part for years by using externally described DS as a form of templating, but the resulting DS occupied storage and could not include arrays, or indeed nested DS. TEMPLATE was long overdue and we love it.

Last but not least, V7. The biggest news in this release was the introduction of OA (Open Access), which was also made available via PTF in V6. Due to an “unfortunate” decision by Rational regarding making OA a chargeable product, it was originally seen as only being relevant to the vendors and users of 5250 modernization tools. But nothing could be further from the truth. Now that the charges have been removed, we’re beginning to see OA attract the interest and respect it deserves.

But OA wasn’t the only new toy in the V7 box. It contained some other very welcome additions. For most of us the capability to use SORTA and %LOOKUP with multidimensional arrays was a biggie ; for those who make extensive use of embedded SQL, the capability to incorporate the long SQL column names in DS defined with LIKEREC or EXTNAME was a major step forward. Those who make extensive use of subprocedures will appreciate that the new RTNPARM option that allows you to return large values from subprocedures with no performance penalty—in fact, it may even give you a performance boost on existing subprocedures. Last but not least, we’ll just give a shout out to the introduction of the new %PARMNUM BIF, which provides a much safer way of handling optional parameters without the need to use hard-coded values.

So that’s it—the highlights of 25 years of RPG. When we were involved in the early stages of the planning and development of RPG IV, we don’t think either of us could have foreseen just how far the language would progress. And in the capable hands of our friend Barbara Morris, we have no doubt that “you ain’t seen nothin’ yet!”


IBMi News Sign Up Today! Past News Letters