Comment On The Other Kind of RPG

Several months back, I featured an arcane programming language called MUMPS. Most of you had never seen before nor, presumably, would want to ever see again. Despite having about as much utility in modern software development as a sextant in modern navigation, MUMPS (or M (or Cache)) is still wildly popular in several markets and shows no sign of going anywhere anytime soon. And to make matters worse, MUMPS isn’t one of kind. There are several other ancient languages like it that just refuse to die. Today, we’ll learn about one of these languages named RPG.

Many years back, Jacobus took a “Programmer, Language Unspecified” job at certain company with a “large team of programmers.” A language is a language, right? Not when that language is RPG. And unlike “Bryan” from the MUMPS article, Jacobus remains an RPG developer to this day.

RPG – or, as it was known initially, Report Program Generator – got its start in 1959 on the transistor-based IBM 1401. At the time, it was a fairly novel and advanced idea. RPG was a generator for programs that produced reports based on declarative specifications. The specs, of course, were defined on a big ol’ pile of punchcards.

Unlike COBOL, RPG was designed for end-users like accountants who were already familiar with tabulation machines. To this day, many RPG programmers come from a non-technical/computer environment (such as accounting), either with an interest in learning computers or with an interest in just getting a job.

One of the novelties of RPG’s design was that it operated as a “program cycle.” Basically, this meant that programs would run in an implicit loop over every record in a file. Control structures such as IF-ELSE and DO-LOOP were simply non existent and, perhaps, unnecessary at the time of RPG's inception.

RPG's Evolution

As technology rapidly evolved and improved in the 60’s, 70’s, and 80’s, RPG mostly stayed the same. New concepts in software development – local variables, abstraction through subroutines, etc – joined RPG only decades later. The “structured opcodes” like IF … END weren’t introduced until the late 1980’s. Things we take for granted – “free format” coding, i.e. the ability to use whitespace like tabbing, spacing, and linebreaks for code readability – was not introduced in RPG until about six years ago (2001).

That last point bears repeating. Well into the .COM-boom, RPG coders were still stuck coding in “fixed format” style. Prior to that, RPG programmers had no choice but to use standard 80-character punch-card-length columns with fixed fields. In this format, the operator (“opcode” in RPG-speak) goes in columns 26-35, the first operand (“Factor 1”) goes in columns 12-25, the second operand (“Factor 2”) goes in columns 36-49, and the “result field” goes in columns 50-63. If you do the math, that means that the fields (“variables” in modern-speak) were restricted to six characters. And of course, all had to be uppercase.

RPG IV, the latest incarnation, introduced the concept of “extended” columns with a more relaxed format. Instead of having one operation (ADD, SUB, DIV, etc) per line, programmers could use the EVAL opcode to do all sorts of crazy things like “A = (B+C) * D”, all with a single line of code. It even afforded programmers the luxury of using lowercase letters in variables.

Slow Evolution, Slow Adaption

Unfortunately, with the glacial speed of improvements to RPG and, of course, the non-technical origins of so many of its programmers, many RPG programmers still code in “fixed format” and prefer opcodes like ADD. And just as well: many RPG shops still haven’t upgraded to the “fancy pants” versions with the features that bear some semblance to modern programming constructs.

Such a programming atmosphere lends itself to a painful, downward spiral of code quality. Which, sadly, isn’t even a metric in many RPG’ers. Success is quantified by how quickly an application can be slammed together and how many lines of code it contains. Why bother trying to learn new things when the language never changes and the environment (AS/400) never changes.

Of course, all this RPG-bashing doesn’t mean that the modern incarnation of the language (RPG IV) is a terrible one. In fact, IBM has recently invested a lot in its modernization. It has “free format” coding, “modern” constructs like functions, local variables, and library code. Heck, you can even use an Eclipse-based IDE to program in it instead of the old green-screen environment. But this doesn’t help solve the culture that they created.

With hundreds of thousands of RPG programs created over thirty years, there’s little motivation in refactoring old code and retraining old coders. Imagine how alien a concept like “variable scope” or “modules” would be to someone who developed code for decades without ever using them. Of course, this doesn’t stop companies from trying.

Teaching an Old Coder New Tricks

A few years back, while Jacobus was at a company that sold AS/400-based systems to the logistics industry, he got to see first hand how painful it was for certain coders to learn “modern” RPG. Specifically, procedures. Prior to the introduction of procedures, code-reuse was accomplished through copy-and-pasting.

There was one procedure named "Putclientno" developed by the company’s technical manager. Of course, with such a name, one would expect the procedure to take a client-no and store it somewhere. To Jacobus’ surprise, the procedure actually returned a client-no.

D Putclientno     PR             8  0
D Contract                      10      value  

  .
  .
  .


P PutClientno     B
D Putclientno     PI             8  0
d contract                      10      value  
 /free

  Chain Contract custcontr;
  If not %found(Custcontr);
     return 0;
  Endif;
   Return CCcontrno;
 /end-free
P                 e

“Bill,” Jacobus queried the technical manager, “why did you name a procedure that gets the client number ‘put’ client number?” The manager responded with a very serious and very sincere answer. “The client number that you retrieve with this function,” the coder explained, “is most certainly going to be used to put it somewhere else. It just makes sense that way!”

From there on, Jacobus knew that modernizing his coworkers might take just as long as modernizing the language.