RPG and Programming

The rather slow acceptance of freeform RPG since its inception has been intriguing to me. For that reason, a recent discussion on  the RPGIV forum has been interesting. Bob Cozzi, a well-known RPG expert, posed a question about how long it took to actually code the implementation of freeform to Hans Boldt, who evidently was on the team at IBM that developed the original implementation.
Hans said that it only took about 1 PM (person month?) to actually code it, but considerably more time was spent in planning. I can believe this. The planning discussions must have been particularly interesting.
One of the biggest things that have slowed acceptance of freeform was the non-implementation of MOVE and MOVEL. This is also the opinion of Cozzi and others in the field. Mr. Boldt touched on this and other issues.
Boldt’s first design included implementation of all opcodes. Others in the group, one in particular, argued vociferously against it. Boldt eventually came around to their way of thinking. As he said, “That design point meant we didn’t have to worry about those goofy multi-part factors.”  (I’m not clear on what that means, exactly. But anyway…..)
Once that was established it was just a matter of deciding which to implement and which not. GOTO was thrown out because, as stated in Nicklaus Wirth’s famous title for Edsger Dijkstra’s article on GOTO, “Go To Statement Considered Harmful”. I could quibble about that, but since it’s been probably 4 or 5 years since I last put a GOTO in a program, there wouldn’t be much point in arguing.
With MOVEL and MOVE however, Mr. Boldt doesn’t understand why people are so attached to those opcodes. He says, “It’s hard to see how these opcodes can be missed given the other options available by free-form opcodes.”
To a certain extent, I agree with his comments. I myself have used MOVE/MOVEL very seldom in the last several years. New opcodes have for the most part been very workable. Using EVAL and many BIFs, I get along very nicely. When EVAL gets a little tedious, I often create data structures to put together data in the desired patterns.
The problem is, I am talking about new code. Old code from the 70’s, 80’s and early 90’s did not have all this neat stuff available. About all you had for data manipulation was MOVE and MOVEL, along with their cousin MOVEA, along with perhaps data structures. From my observations over the years, I would say most programmers did not avail themselves of the help even data structures could provide; they did their work with MOVE(L). We are not talking about an easily disposable opcode like FORCE; we are talking about opcodes that appeared in almost every non-trivial RPG program before RPGIV, and most of the trivial ones. They used the opcodes to change data types (from alphanumeric to numeric and back). Above all, they used MOVE to manipulate strings, piecing together long strings from five or six (or more) smaller ones. One can complain that this is a very kludgy way of doing things, but this is all we had to work with. I would suspect that there are millions, if not tens of millions, of MOVEs in the legacy code sitting on today’s AS/400s (or whatever we’re supposed to be calling them today).
So what do we do in freeform once MOVE is taken away from us? As pointed out in the post I referenced yesterday or the day before, we must choose among 10 or 15 alternatives, depending on what we want to do - which in a sense is a demonstration of the power of the opcode. There is no easy conversion; it is not the same thing as changing  KEY   CHAIN    MASTER  to CHAIN KEY MASTER; . I don’t think even artificial intelligence could do even close to a good job of determining the best conversion; Linoma tried, but some MOVEs are just untranslatable without human eyes and brains to analyze them.
Therein lies the problem. If you rule out MOVE in freeform, a human must determine the best way to translate it to freeform. It simply isn’t financially practical to spend resources changing massive amounts of fixed-format code to freeform by hand, and the utilities available for automatic conversion do not do a clean job. You can use Linoma’s software; you can use Websphere’s conversion facility, which does not handle the MOVE and does not even attempt to do the indentation; there may be other utilities around. In the end, to convert legacy code, you can convert it to a degree automatically, but you will still be left with MOVEs to contend with by hand. You end up with ugly flipflops between free and fixed format that may even be harder to read and deal with than the original fixed format code.
It is very nice to say, that when we modify a program, we will also change it to freeform. But that is a slow way of converting what might be hundreds, or even thousands, of programs on your system. Remember, converting a MOVE to something else is not the same as reformatting a CHAIN; it must be carefully tested.
So, while freeform may ultimately win out, it could have been done a lot more readily if MOVE had been implemented in freeform. The more I think about it, I wonder if someone’s ego got in the way, someone who said, “I am going to teach these plebeians how programming SHOULD be done, instead of using these operations that no other reputable programming language uses.”  (Down, XFOOT, down!!!  Don’t bite him!)
And to think it could have been avoided by allowing the conversion of  MOVE  STRING1   STRING2  to the freeform equivalent:  move   string1    string2.

I didn’t think I’d be considering free-format RPG so soon as a final solution for the current RPG programs on the system at work (some of which date back to the 70’s), but a number of interesting events have taken place.
Our IBM representative made us aware of a software package that accomplishes the conversion of RPGII, RPGIII, and RPG400 programs into true RPGIV. This means (among other things) ditching the left-hand indicators and attempting to really use more modern operation codes. If you are at all familiar with what would be necessary, you can appreciate how difficult this task would be without some kind of automation. The painstaking code changes and testing would be incredible on a code base of any size.
This package is called RPG Toolbox, from Linoma Software.
So we downloaded the trial version, which allows 10 source conversions from another RPG dialect - or even RPGIV that has simply been converted from an older format using IBM’s CVTRPGSRC utility. CVTRPGSRC simply reformats old code into RPGIV syntax; it does not attempt to modernize it. We converted a source member with a lot of left-hand indicators, and we were impressed how it converted into a reasonably neat format without those indicators. What really impressed me was that it would attempt to convert a series of MOVE statements, which was commonly the method used to piece together larger fields, into EVAL statements. This could be a dangerous technique, but the RPG Toolbox utility carefully analyzes the code to make sure it is safe. In the manual, it describes how it makes decisions about code conversion; if one is interested in this product, that person would do well to download and read the manual before making decisions about what the program should do in the course of conversion.
I also had an inspiration- why not use it to convert RPG IV to freeform? In earlier posts, I have declared my reservations about how valuable freeform is. But, if it’s easy, why not live dangerously? So I tried converting one of the RPGIV programs in my file cross-reference system to freeform. The results were impressive. It looked VERY good. The more I looked at it, the more I liked it. So I said to myself, why not convert ALL our code to freeform?
But then my younger cohort brought me back down to earth. He wasn’t so sure that would be a good idea. So we converted the old-format code referred to above into freeform. The results were messy. There was much code that simply could not be converted, often involving the MOVE and MOVEL opcodes. (I have also commented on this previously.) When this happens, the free-format code is enclosed in a /FREE - /END-FREE set of compiler directives and the code drops back into fixed format. Switching back and forth between free and fixed can be maddeningly ugly.
So I have backed off the idea of a total conversion to freeform RPG. But we still feel that converting our code to a clean RPGIV that uses as much as possible of RPGIV’s modern syntax and opcodes would certainly be a good thing; and it appears that it would be relatively safe. We have ordered the software. Where the conversion of a program to freeform would not create too messy a result, we can still convert it.
I was also surprised to learn how quickly the most experienced one on our crew would take to freeform. He first started programming in ALGOL; so freeform is not really that much of a leap for him. He has in the past several weeks written new programs in freeform RPG, of his own free will. My other partner has a Pascal/Java background; so freeform would come “naturally” to him. I am the one who will take some getting used to the idea.

Subfile processing is an integral part of RPGIV data entry and data display. To be a real pro, you need to handle them properly. There are any number of ways to build and maintain them. Depending upon your level of expertise, you can do really sophisticated data processing tasks with subfiles. (Yes, I know that phrase data processing is so 1970’s.)

Dealing with them at my place of employment is an ongoing task. My two fellow programmers, though having much experience in programming, are relatively new to RPGIV. To help enhance their skills, one of them bought the excellent book by Kevin Vandever, “Subfiles in RPGIV”.

One of them was using it to help him build the first subfile program he had ever written from scratch. And wouldn’t you know, his techniques were different from mine! And the author had used my technique when he first started programming subfiles, but he had found a better one. Oh, my.

For the uninitiated, subfiles are a way to handle update and display of data files, by allowing you to display multiple instances of data in (usually) a columnar format, then treat each line as a separate data record. In RPGII, subfiles were not available; to process it, you had to plug your file data into arrays of information, each data field in an individual record linked by being the same array element in multiple arrays.

Anyway, the author recommends a technique that is clean and efficient. He uses the DDS keyword SFLNXTCHG to allow the programmer to flag for further processing data in a record that has been changed. The operating system keeps track of changes, and this allows the programmer to process only those subfile records that have been changed by the programmer. This is done by using the READC (Read Changed record) RPG opcode. Using SFLNXTCHG with an indicator allows the programmer to mark a line of data as “changed” when it processes the second time around. If one entered erroneous data in error, and the program would not accept it, the data would still be marked as “changed” and the record would be read the next time around by the READC opcode, even if the data entry person did not correct or change the data.

My approach, the way Mr. Vandever set aside, is to keep track of the number of records (entries) in the subfile. To process the subfile, I CHAIN to each subfile record by relative record number, whether it is changed or not, and process the data as needed. I can do this as many times as desired.

Why do I do it my way? Because I’m an ignorant so-and-so, I guess- or at least I was when I was learning many years ago how to program subfiles. I vaguely remember attempting to use READC to process only changed subfile records. However, I was not aware of the SFLNXTCHG keyword; and when I would read a subfile record and find an error, I couldn’t see how to tell the system to process the record the next time around. Suppose the screen had five subfile records displayed. I changed two records, and one of them was in error. Once I fixed the one in error and the program looped through with the READC opcode again, it would not pick up the correct one from the previous pass because it couldn’t tell it has been changed! When I saw an example of the CHAIN technique, I realized that it would always work, so I stuck with that technique.

So do I change now to the more efficient technique in the future? Wellll…. probably not. Being a creature of habit, for one thing; and the fact that changing my technique will not gain me all that much and would make the “read subfile” task more complex.

But what about all the unnecessary CHAIN operations, which on a large subfile mean an awful lot more subfile accesses than necessary? If you have read my blog from the start, you might remember when I told about a hissy fit  I had when I worked on a program where a previous programmer read a detail data file by CHAIN instead of READ and increased the processing time by a factor of 10 – from 15 minutes to 2.5 hours.

I suppose that I have been corrupted by the greased lightning bottled in the latest machines. In my file cross-reference program, I load source files into subfiles so that you can drill down into the subfile and find out file characteristics, even view the data in the file by putting the cursor on a file name and clicking a function key. When I tell the system to display source, it can put 9,999 lines of source to the subfile in less than a second. Why sweat the difference in processing one record with READC versus, say, 12 when using CHAIN? In a large installation with hundreds of users on a slower machine, perhaps it would be a concern- but not now. My concerns about performance are pragmatic, not ideological. As I have said before (as a matter of fact, in that previous blog post I mentioned above), I don’t sweat over nanoseconds.

Also, at least with reference to my cross-reference program, using READC is irrelevant. I do not change the subfiles in any way. They are simply a jumping-off point for further processing. I use EXFMT (which means write the format, then accept input) to display them, but only to allow the input of a right-click or a command key or a search argument to use with a command key.

A minor quibble would also be that an edit that relied on READC would catch only errors that had been introduced by the current data entry operator. There is no way to guarantee that the data in the subfile is error-free when it is first displayed, especially if the data is also updated by other programs. If you edit every line, you can check for errors in all the data, including preexisting errors.

So my partners are free to use the new techniques, but I am not likely to choose to do so in the future.

I work on code that, when I came to work for my client, was essentially RPGIII/RPG400 or older. Some of the code had been implemented way back in the 1970’s and was migrated forward as newer machines were installed. And the code showed it. (I have found interesting the large number of 80 and 96 byte files in some of the systems, remnants of old punchcard processing programs.) You haven’t lived until you’ve attempted to update a program that has grown over the years to be a 10000+ line, indicator-laden monster. If you’ve been away from the program awhile and you need to make a non-trivial change, you need to spend part of a day, at least, reviewing the program’s processing.

I am normally conservative about program changes. I generally do not rip apart code and rewrite it, especially if it is not broken. But if a program is to be revised, I do generally at least convert it to RPGIV before making even a minor change. As a phrase used by one of my favorite literary characters (Anne of Green Gables) says, doing this allows “more scope for imagination”.

I was making code changes for a conversion project I was working on when I came across a particular program I had seen before and shook my head at. But for some reason, this time something snapped. I just HAD to change a particular chunk of code, even though the code in fact worked. No errors. But how far to change it? I will explain what I did. In the end, what I do will likely be seen as good by some, too intrusive by others, and  not radical enough by still others.

(more…)

One of the more interesting things about freeform RPG, at least currently, is its support of the MOVE/MOVEL RPG operation codes. It doesn’t.
For those not so familiar with RPG, MOVE (move right) and MOVEL (move left) are codes that you will find in almost any standard RPG program. What do you do with them?
You can:
1. Move a string into another string. If the target string is smaller, the move ends with the filling of the string. For example, assuming the field MONTH as a 9-long string with value “NOVEMBER” and a 5-long string RESULT:  MOVE MONTH RESULT results in ‘MBER ‘ ; MOVEL MONTH RESULT result is ‘NOVEM’. If the smaller field is MOVEd to the larger, what is left remains unchanged (unless the move is given a code (p) which causes it to be filled with blanks). If RESULT was ‘NOVEM’, MOVEL ‘123′ RESULT would produce ‘123EM’
2. You can MOVE strings to numeric fields, and strings to numbers. In this case, the system will try to convert the string to numbers; this is no problem, especially if the string is already a number.
3. Move strings and numbers to DATE type fields (which RPG can manipulate with other techniques, such as adding a month to the date), and vice versa.
In fact, 14 pages in the RPGIV manual is devoted to examples of how to use the MOVE opcode. (As we said above, MOVEL just starts from the left. Almost as many pages are given to MOVEL).
You would think at first that IBM would want to use this code, in view of its widespread use and of its power. Syntax would not be an issue; I deliberately did not attempt to put my example above in fixed format, just to show how obvious the syntax was.
But, what does the IBM manual say about MOVE? To quote:
“Free-Form Syntax: (not allowed - use the EVAL or EVALR operations, or built-in functions such as
%CHAR, %DATE, %DEC , %DECH, %GRAPH, %INT, %INTH, %TIME,
%TIMESTAMP , %UCS2, %UNS, or %UNSH )”.
To this list I would add %SUBST(substring), at least.
I can think of no practical reason why the implementers did not simply allow MOVE into freeform. Perhaps it’s because I’m just an ignorant junior college grad, from when they didn’t even have CompSci courses in JC. Since I am not a computer science major, to me the implementation would be a snap; when the compiler sees “move field1 field2;” in freeform, do exactly the same thing you would if you saw MOVE FIELD1 FIELD2 in fixed format. (Copy the compiler code! What a revolutionary idea!)
I, for one, think the problem is ideological. MOVE (along with its cousins) is too powerful a code. Since high school grads (like me) know how to use it, it obviously is too difficult for CompSci graduates to understand; you must replace it with another opcode (EVAL) and one or more of at least 12 BIFs listed above. Makes it easier. Yeah, right. We must make it simple so the ignorant Java programmers can understand. Pardon me while I get ticked off by intellectual condescension. The compiler writers are evidently trying to pry us away from an operation they feel is somehow inferior. Never mind that it works reliably, precisely, and elegantly.
Never mind that you have to be very careful how you use the BIFs, since you might not end up with the exactly equivalent result. You wouldn’t have to bother if you didn’t change it in the first place. Multiply this by the millions upon millions of MOVEs and MOVELs that likely exist in existing code, and you begin to see the problem.
The code will almost certainly be longer and likely more complicated if you attempt to convert the code. You would think brevity would be prized, since it seems such a virtue when it goes the other way, when they come up with a BIF that seems to do the job more succinctly than its fixed-format equivalent. Apparently here, they are not shooting for brevity; and I find it hard to see how they enhance the clarity of the code by avoiding MOVE.
Frankly, if they are trying to promote the use of freeform, I think they are shooting themselves in the foot by not implementing MOVE. From what I have read on the RPG forums, the lack of MOVE support stands in the way of easy freeform conversion. The fixed-to-freeform converter cannot handle it, so a /END-FREE must precede it, dropping the code back into fixed-format. Many other opcodes can be handled more or less elegantly using BIFs; not using MOVE in freeform often ends up forcing the programmer to use some Rube Goldberg BIF to try to salvage the situation.

I can only wonder why they are taking an ideological stand on this subject. “Dumb” is the nicest word I can think of with reference to their decision.

One rule repeated in almost every discussion of programming is, “Don’t re-invent the wheel.”
The idea is, if someone has written a program, routine, or system to solve a particular programming or business problem, it is foolish to waste programmer time and other resources writing another routine to accomplish the same thing. With RPG now more capable of working in a mixed-programming language environment, the suggestion now often is, if a program in C solves a programming problem, it is better to call the C routine, by whatever means available, than to insist on writing it in RPG.
As a concept, I think it makes sense. At least superficially, it seems pointless to duplicate someone else’s effort. Since often you don’t know the identity of the person who wrote the original routine, I like to call the practice “Depending on the Kindness of Strangers”, after the famous line from Tennessee Williams’ play “A Streetcar named Desire”.

But when it comes down to the implementation of the practice, I sometimes think that depending on the kindness of strangers in programming is about as good an idea as it was for Blanche Dubois - in other words, not very good.

(more…)

#1. And the best reason to code in free-format syntax is: We can finally see the structure of our code as we work with it!

Just a few more words on that last point. Free-format is just that - free. A programmer can choose to start a statement in any column after column 7 and continue through to column 80. So nested logic can now be indented, allowing us to craft code that conveys an immediate and intuitive sense of the order and conditions of execution. Nested fixed-format code can be difficult to work with, and if it’s deeply nested it can be an outright nightmare. This problem is removed in free-format RPG. Properly indented nested control structures tell the story at a glance. It simply takes less mental energy to understand the intent of well-written free-format code.”

Before we go too deeply, note the use of “weasel” words. Weasel words are words that you can use to show, if someone questions you on the validity of a claim, that you qualified it so that it didn’t say what he thought it said. (I learned the expression in a book on advertising.) Note- nested fixed-format CAN BE (not IS) difficult to work with. PROPERLY INDENTED (not ALL) control structures tell the story at a glance. And the reference to WELL-WRITTEN free-format code. This allows you to say that if the nested code is obscure, it was not properly indented or well-written. Somewhat different than the common unqualified claims that free-format code IS easier to understand.

We are not under the illusion that what follows will convince people to use fixed format instead of free-format RPG. What we do hope is that a free-format advocate will look at the whole situation with a more open-minded attitude than he does now, that it is not an open-and-shut case that free-format is easier or more usable.

But to proceed:

1. Note that word “intuitive” used again. As with our previous posts, we ask: Intuitive for whom? And the answer is the same- intuitive for the person who has been trained on block-structured code.

Brian Kelly, a noted ex-IBM Systems Engineer, author, and lecturer, gave these comments in a discussion of what he did and didn’t like about RPG IV:

“Hey, I liked RPG IV when it came out with the larger field sizes and the D: spec and the date operations. I am not as fond of the new RPG with its ILE connotations, difficult to understand procedure prototyping, and Java like built-in functions. I would have been happy without those. I liked being able to debug a customers code by looking on the right side of the RPG page looking for where a variable was changed or an indicator was turned on.” In other words, he liked fixed format, where he could expect to see result fields and indicators on the right side of the page. Free-format is not so easy or comfortable for those who are used to fixed-format code.

But perhaps you would expect that. These old stick-in-the-mud, died-in-the-wool coders are just too set in their ways, aren’t they? So let’s look at it a little more deeply. (more…)

Continuing with the article in which an RPG programmer describes why he loves freeform RPG so much, we find #3:
“’Eval’ is optional in free-format unless right-adjusting a character string or half-rounding a number. ‘Eval’ simply serves as a placeholder in fixed-format when writing extended factor2 assignment statements. It satisfies the compiler’s need for a non-blank value in the op-code column block (save for the exceptions noted above).”

Now, there’s a good reason!
EVAL is the logical equivalent of the LET keyword in BASIC.
That is, saying LET x=5 is the logical equivalent of EVAL X=5.
In BASIC, you can simply say, instead, X=5. Now, in freeform RPG, you can simply say, X=5; (and don’t forget that semicolon!).

BIG WHOOP. I’m sure not having to key in those four characters when you want to assign a variable a value will vastly improve your productivity. For me, actually keying in a program is the easiest part of programming. Even for a hunt-and-peck typist like me, keying in EVAL takes less than 2 seconds- one second once I’ve got that combination memorized by my fingers. If I don’t have to key 200 EVAL opcodes, that would save me about 1.5*200/60= about 5 minutes, not much in the larger scheme of things, since I would be taking anywhere from 5 to 20 seconds (for a particularly long line with multiple nested parentheses), maybe more, per line.

And then there’s #2:
“Longer field names are more easily accommodated, especially the typically more wordy subfield names in qualified data structures. Longer, more complex expressions can be written on each line. Once written they are more easily understood, since they’re likely not so spread across multiple continuation lines.”

I have to quote a line from one of my favorite books, “The Psychology of Computer Programming”, by Gerald M. Weinberg. Some of the language references are dated, since it was published in 1971, but its essential points remain valid. In the chapter “How Can We Study Programming”, he presented this beautiful line of PL/I code to consider what programming insights could be done via introspection:

ANGLES(I)=2*ATAND(SQRT((S-A(IND(I,1)))*(S-A(IND(I,2))))/(S*(S-A(IND(I,3))))));

Weinberg comments: “Now, a single case such as this contains many insights into problems in computing: the proper size of statements, the choice of data structures, the arrangement of different parts of a program, the use of parentheses rather than other techniques for decomposition, the design of compiler and execution-time diagnostics, and techniques for learning and teaching programming.”

Indeed. The very least it should teach us is that being able to create long, complex expressions is not necessarily a virtue. When you have to resort to dissecting three or four (or more) elongated lines of almost 75 characters each, you probably need to break up the statement, so you don’t lose the next programmer (or yourself, six months later) in your beautiful mathematical expression.

With the EVAL statement, very often (especially when piecing together a long string), I and others will often have to put together a long string of concatenated lines (with a + sign); we are forced to break them up, so will often line up the code, indenting and spacing it so the reader can see the field relationships readily. If we had nearly unlimited space, there would be no incentive to break up the line into manageable pieces. Being able to create long lines of parentheses four levels or more deep is not an advantage. We are not trying to derive complex mathematical formulas; we are attempting to write a legible program.

If you would say that you would keep the lines short, then the above “advantage” disappears.

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.

I came across a discussion of freeform RPG and why the author felt it is the way to go rather than the fixed format , old-style. I would like to analyze it in some depth, not to make fun of the author, but rather because his views are representative of those who think the way he does, and they are stated very concisely. (This may take several posts, so bear with me.)

What is his reason number 4 for using RPG freeform?

“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.”

We will ignore the condescending reference to magical storied history and sand on the beach for the moment. and concentrate on other things first.

1. Is freeform, whether in RPG or other languages, INTUITIVE?

Well, what is “intuitive”? According to the Webster’s On line Dictionary:”1 a: known or perceived by intuition : directly apprehended <had an intuitive awareness of his sister’s feelings> b: knowable by intuition <intuitive truths> c: based on or agreeing with intuition <intuitive responses> <makes intuitive sense> d: readily learned or understood <software with an intuitive interface> .

And what is intuition? “1: quick and ready insight 2 a: immediate apprehension or cognition b: knowledge or conviction gained by intuition c: the power or faculty of attaining to direct knowledge or cognition without evident rational thought and inference.”

The most obvious applicable meaning is “readily learned and understood”. Certainly some of the languages he mentioned might be intuitive for some; but I thought RPG was readily learned; I learned it in just a few informal sessions by reading a textbook when I didn’t know a physical computer from a dustbin and had no concept of computer science and had never seen a computer language. I would be interested in seeing how many people learned C or Perl – or especially Java- by just being given a computer book for the first time and told, “read this”.

About 20 years ago, I bought a C compiler for my microcomputer and a C textbook. I wanted to see what it was all about, and I was willing to spend money to do so. But I got into it and started seeing things like int main(), all the different data types, and { and } and a= (b= (c=25)) and if (age ==40) – just for starters- I looked down from my RPG II heights and said “You’ve gotta be kidding.”

That last reference is especially intriguing. Nicklaus Wirth, creator of Pascal, Modula-2, and Oberon-2, wrote an interesting article about good and bad ideas in computer science. Here’s what he said on that subject:

“A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x. Algol corrected this mistake by the simple solution: Let assignment be denoted by “:=”.

“Perhaps this may appear as nitpicking to programmers who got used to the equal sign meaning assignment. But mixing up assignment and comparison is a truly bad idea, because it requires that another symbol be used for what traditionally was expressed by the equal sign. Comparison for equality became denoted by the two characters “==” (first in C). This is a consequence of the ugly kind, and it gave rise to similar bad ideas using “++”, “–“, “&&” etc. ”

So C came up with the bad idea c== 5; when you first come to it, being acquainted only with “=”, you look at “==” and your first thought is, “What on earth is that?” I place in that same category an expression like x+=1. You don’t know C; you know what a “+” is; you know what an “=” is; but what is a “+=”? I’m sorry folks, but that is not intuitive.

You think such stuff is intuitive not because it is truly intuitive; you think it because you have been raised to expect data in the format x=Y+3 in your “Introduction to Programming” or “Introduction to Computer Science” courses. You may have seen something like it in BASIC, and it fits the pattern. I was raised on X ADD 1 Y. I think THAT is intuitive.

Am I wrong? Is not X ADD 1 Y practically the same structure as 1 + 1 = 2, the mathematical structure you learned in first grade, a long time before your Computer Science courses? And, even if you allow the “bad idea” to be used, is not ADD 1 X easier to comprehend than X+=1? Which is REALLY more intuitive?

So the block-structured languages mentioned are not innately “intuitive”; whether they are more intuitive than fixed-format RPG depends entirely on where you are coming from. And whichever direction you come from, can you really say with a straight face that X+=1 would be more readily comprehensible than ADD 1 X for a new programmer?