You don’t write compilers in COBOL

To pursue the topic I began in my previous post:

Calculation syntax now looks more like the intuitive mathematical-function-like syntax found in most other modern programming languages. No doubt the Factor1-OpCode-Factor2-Result sequence has some magical storied history, but at this point it should be considered sand on a beach that’s been washed away by common sense and better practice. If I can write intuitive code in Java or C or Perl I should be able to do the same thing in RPG.”

2. Does it need to be like other modern programming languages?

I submit that it does not, and that those who are trying to make it so are making a grievous mistake.

From its inception, RPG was not a general purpose programming language. It was not designed to calculate formulas or functions. It was not designed to create new operating systems, like C was. Syntax like F1 ADD F2 FLD3 and MOVEL STRG1 STRG2 was not designed to impress a compiler writer. Pure and simple, RPG was designed to push data around. It was designed to read data files, manipulate them, do a few calculations on them and spit them out on a report, another file, or (later) a screen. To do this, it has many powerful op codes, in a few cases operations you don’t see specified in other languages. Operations like XFOOT, used to sum all the values in an array and store the result in a variable. Even MOVE and MOVEL, operations which to this point they have not chosen to implement in freeform RPG. MOVEL moves data and, in some cases, will even do a conversion from alphanumeric to numeric.

Also, RPG was intended to be terse; in the mind of programmers today, even too terse.

Consider this calculation, one line of RPG:

C  10 11 12TOT          COMP      50               202530

Here is the pseudocode equivalent:

IF   (*IN10 and *IN11 and *IN12)
    EVAL   *IN20=*OFF
    EVAL    *IN25=*OFF
    EVAL   *IN30=*OFF
    IF     TOT>50
        EVAL *IN20 = *ON
    ELSEIF TOT<50
       EVAL *IN25= *ON
    ELSEIF TOT=50
      EVAL  *IN30=*ON
   ENDIF
ENDIF

A lot of instructions packed into one line.

Put simply, RPG is a business programming language, like its cousin COBOL. Its intended purpose is to handle business data. Business people can write it without much trouble, if they choose to learn. Computer operators learned it without formal training, on their own. You did not have to know computer science. The syntax was rigid, fixed in format. Just fill in the blanks. Describe the input, insert data manipulation calculations, and lay out the output. It may be contrasted with Pascal, which Niklaus Wirth designed with not much emphasis on input and output. With RPG, you lay out with just a few specifications what the printer does on page overflow, define skipping and spacing, put your data in a precise place on the print line, and format numbers, if necessary, with edit codes or edit words. With programs in other, general-purpose programming languages, you have to jump through hoops to get precise formatting. With RPG, you know how many spaces a field will take up on a screen or printout. Many general-purpose languages are not nearly so precise.

Some languages have an INTEGER data type; how much space it takes up may vary even with the compiler. In RPG, you define the integer as 10 bytes long, with 0 bytes to the right of the decimal point. RPG never cared (until relatively recently, when adding floating-point handling), whether a number was an INTEGER or a REAL; it was just a number. The number 10 was the same as 10.000000; it might have to do some fancy manipulation under the covers to add 10 and 10.000000, but the programmer doesn’t have to care what kind of numbers they are; he just adds them.

(By the way, in this blog I use “he” to designate both male and female; there is no good pronoun to designate both sexes with the same word in English. He/she or She/he is clumsy, and alternating the use of “he” and “she” is just silly. Anyone who can’t figure out that using “he” means both men and women here, based on longtime English usage, probably isn’t smart enough to be reading this blog anyway.)

When they take RPG from its roots, it becomes an attempt to transform it into a clone of another language- something that is not needed and in fact makes the language more clumsy and bloated with often no gain in function. Take, for example, the XFOOT operation above; and take total=%xfoot(arrayname) - please. All it accomplishes is to make it pretty for the general-purpose programmer who the compiler writer is trying to persuade to give RPG a try. I don’t think you would want to hire a programmer in any language who would find XFOOT ARRAYNAME TOTAL difficult to understand. I don’t see anybody trying to reformat COBOL to appeal to the exalted programmer of Java.

COBOL has evolved over the years to become the pre-eminent business programming language, with even object orientation embodied in the latest COBOL standard. And yes, there is still new code being created in COBOL. One thing I found interesting is that they have managed to update COBOL without feeling under compulsion to make it look like Java. COBOL has a COMPUTE statement, just like RPG has an EVAL opcode; but no attempt has been made to create COBOL functions, to my knowledge. Why not? It’s not needed to perform business-type calculations; and I can’t see how it would avoid looking ugly. Evidently those in charge of the standard for COBOL recognize that, after all, you don’t write compilers in COBOL. If only the designers of RPG would respond in like fashion.

2 Responses to “You don’t write compilers in COBOL”

  1. Computer Programming Functions Says:

    I have read several articles about computer programming functions but this post is very interesting to me compared to the other articles when i found it on Wednesday.

  2. Larry Holder Says:

    Long live COBOL (and RPG). I wrote tons of COBOL / CICS during my early years with Wal-Mart DP in the early 80’s (in what I call the “fun years”). Followed by more of the same here at UT Martin (before they switched to an Oracle-based application and the kludge they call PL/SQL). COBOL will never die. As far as functions, if I needed one, I wrote it in Assembler and called it (long live Assembler!) from COBOL. I look at C and Java stuff and think, what a mess. Those who dismiss COBOL or think it is dead or dying are quite misinformed. And for doing what they are meant to do, COBOL and RPG are classic workhorses. Ever seen a report written in C? What a joke. Long live COBOL! Long live RPG!

Leave a Reply