Avoid your IBM i crisis with ASNA!
Give us a call in the US at 800.289.2762 or in Spain at +34 902 365 787.
Visit us at asna.com or email us at email@example.com.
In the 60s, a class of computers appeared that were much smaller than mainframe computers of the era. This class of computer was dubbed "minicomputer" in most circles (which, in today's terms, is ridiculous because these "smaller" computers were often as big as refrigerators). Minicomputers were installed by many businesses as their first foray into electronic data processing.
IBM's marketing department went out of its way to ensure its customers knew its junior line of computers weren't just minicomputers and should be called "midrange" computers. The "midrange" term stuck and over time became the industry nickname for IBM's line of RPG-powered computers.
For all intents and purposes, RPG is exclusive to IBM midrange computers.
Beyond IBM midrange machines, Burroughs, Digital, HP, Sperry, VAX, and Wang each once had RPG implementations. Today RPG's use outside the IBM midrange is extremely isolated. For all intents and purposes, RPG is exclusive to IBM midrange computers.
RPG was developed by IBM in 1959 as a programming language to build solutions to replace punched-card processes. IBM had RPG-based midrange products prior to 1977, but they were mostly punched-card computers. This timeline starts with the IBM System/34—which is when RPG moved away from punched cards and connected multiple online users with display terminals. (Here is a more detailed breakdown of the history of the AS/400's operating system.)
RPG and COBOL both debuted in 1959.
1977: System/34 with RPG II. RPG was mostly a punched-card language until 1977. That year IBM introduced the System/34 and its version of RPG, RPG II. The S/34 was a very popular multi-user, multi-tasking computer.
1979: System/38 with RPG III. To be competitive for larger business, IBM introduced the System/38 in 1979. It featured RPG III, which was an enhanced version of RPG II.
1983: System/36 with RPG II. The S/38 was a very expensive machine (starting at 90K in US dollars in 1979). In 1983, IBM introduced the follow-on to the S/34, the System/36. The S/36 used the same RPG II language the S/34 used.
1988: AS/400 with RPG/400 (aka RPG III). Aiming to consolidate its midrange line, IBM introduced the AS/400 in 1988. Since the AS/400's introduction customers have either migrated to the AS/400 or moved to another platform. By 2000, IBM no longer produced any S/3x models. The AS/400 RPG dialect was called RPG/400. At the time of its introduction, RPG/400 was simply a rebadged RPG III brought over from the S/38.
The AS/400 debuted on June 21st, 1988. The "AS" was short for "Application System." When the AS/400 shipped there were more than 2500 software packages available for it.
1994: RPG IV introduced on the AS/400. By 1994, RPG/400 was still very much the same compiler that originally shipped as RPG III in 1979. That year IBM introduced the Integrated Language Environment (ILE) for the AS/400 and with it an enhanced RPG version called RPG IV. RPG IV was also known as ILE RPG. Although RPG IV acquired new facilities for partitioning large applications, its syntax and function remained nearly identical to RPG III.
2000, 2006, 2008: AS/400 renaming. There were three significant IBM midrange marketing rebranding efforts in 2000, 2006, and 2008. Technically, though, the 20-year period 1994-2014 was a very static time for RPG; there were, however, significant hardware changes. The most significant of which was the convergence of the System i and System p (what used to be the Unix-powered RS/6000) platforms. Until this change, the IBM RPG midrange platform used specialized (and more expensive) hardware than most of its competitors. This convergence (which ultimately led to the "Power" platform moniker) helped commoditize IBM's midrange RPG machines which made them more competitive pricewise.
2014: RPG IV gets improved syntax. Until 2014, RPG's syntax was quite literally driven by a punched-card idiom. Called fixed-format, this syntax required operand and operation be in specific columns. At a glance, this syntax looked a little like assembler language. In 2014, RPG acquired a free-format syntax as well as better language semantics. Prior to 2014, RPG didn't have the concept of variables local to a routine; all variables were global. In addition to its vastly-improved syntax, this update also provided local variables and several other syntactical improvements.
Figure 1. IBM/RPG Products Timeline
IBM's RPG midrange platform and its operating systems has had several names over the years:
Although it drives IBM i purists nuts, the name "AS/400" is still frequently used as a nickname for the modern "IBM i" platform
Today the name "IBM i" refers to either the platform or the operating system. Many users today still call the modern IBM i platform "the AS/400." True blue IBM fans insist it's denigrating to call the platform the "AS/400" today—because, they argue, so much has changed under the covers.
Don't let all of the renaming confuse you. The AS/400, the iSeries, and the System i platforms and operating systems are no longer available (and rarely even in use). The IBM midrange platform in use and available today is the IBM i running on IBM's Power platform (introduced in 2008, IBM's Power hardware runs either IBM i or Unix/Linux operating systems).
It's best to call the IBM i platform "IBM i," but if you slip and call it "AS/400" most people familiar with the platform will understand that you're simply using an old muscle-memory name for the current IBM i platform.
Like the platform, IBM's midrange computer operating system has had several name changes over the years. While there have been advances and improvements, since its introduction in 1988 as OS/400, the operating system has remained essentially the same.
|System i||System i|
|IBM i||IBM i|
If you slip and call your IBM i "the AS/400," that's OK. Old habits are hard to break!
With a little history under your belt, let's put this RPG history lesson in the context of the challenge of persisting your business. 73% of respondents to the 2020 Help Systems IBM i Marketplace Survey say they are running "homegrown [RPG] applications." It's a fair bet that many of those homegrown applications currently running on the IBM i started life on a System/3x platform—which means lots of RPG business code was originally written with very old RPG compilers and with very old RPG techniques.
It's also a fair bet that a good number of the RPG programmers who originally wrote these old applications are still with the company and can still maintain and enhance them. However, how long are they going to be with the company? RPG hasn't been taught in colleges for at least 20 years. When RPG programmers retire, who will do this work?
Even at RPG's zenith RPG college classes were hard to find.
Even at RPG's zenith RPG college classes were hard to find. In some cities community and state colleges offered such classes—but those are very hard to find now. There are still a few RPG specialists in the world that teach RPG, but like all other RPG programmers, these teachers are also near retirement. Even if you can find a programmer willing to learn RPG, resources are limited.
While the term "legacy code" has roots in US military technical documents from the 70s, in the 90s "legacy code" was co-opted to reference aging business applications—and often in a denigrating way. "Legacy code" is a weak, vague moniker that needs to go away. It was mostly used as a polite way of saying "old code."
It's quite likely today that much of your "legacy code" has been expunged. By now, many IBM i shops have replaced old vertical applications (ie, old legacy code), that didn't run the unique parts of the business, with third-party canned replacements.
Your surviving RPG code base is a highly valuable asset and needs ongoing care and feeding.
The code that remains isn't legacy code. What remains is your finely-tuned RPG code that has survived the test of time and continues to run your critical business applications. That code is very likely solving the same problems as well now as it did 20 or 30 years ago. However, business rules change. Regulatory compliance rules change. Environmental changes and upgrades can make bugs appear. Your surviving RPG code base is a highly valuable asset and needs ongoing care and feeding.
Adding modern features to an RPG application on the IBM i is quite challenging.
That code was written to solve business challenges as they existed many years ago. And these core challenges (eg, aging whiskey, coordinating aircraft repair parts, or managing complex legal billing and time management) may need to be solved exactly as they were in in 1985. However, as technology matures, processes need updating. You may need to connect your system-of-record to Raspberry Pi-driven humidity collectors, or you may need a mobile solution with which workers scan bar codes with their phones to reorder inventory, or you may need to integrate business partner Web services to check external inventory levels. Adding modern features like this to an RPG application on the IBM i is quite challenging.
IBM has added some features and facilities that expand RPG's abilities to support more modern application development techniques. However, just because it can doesn't mean you should. With RPG programming talent on the decline, is this the time to double-down and deepen your RPG technical debt?
You must take steps today to solve the challenge of how you're going to maintain and enhance your RPG applications through the next decade and beyond.
© 2021 ASNA. All rights reserved. v1.355