Archive for the ‘RPG’ Category

When and How to Upgrade Code

Tuesday, December 30th, 2008

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…)

No MOVE to freeform

Monday, October 27th, 2008

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.

Am I Getting Lazy?

Saturday, October 25th, 2008

It has been too long since my last post. What’s going on? Well, for one thing, I’ve done a couple of articles for work.com (a bit of shameless self-promotion here) , on “recovering data from a dead computer“  and another on “natural language processing” - text-to-speech and speech-to-text software.  I’m actually getting paid for my writing; and though I’m getting paid less than minimum wage (on an hourly basis) for doing it, it really is neat for your writing ability to be recognized.

But I haven’t really been all that busy writing those things. It’s kind of hard to explain. I think the problem is that I have convinced myself that everything I write must be a work of art, with detailed logic, clever phrases, and quotations. After the first flush of enthusiasm for the blog wore off, I found it not so easy to write through the brain fog that envelops your mind when you are tired at the end of the day. I have the energy to read my e-mail, surf my favorite web sites, but not enough to sustain several hours of determined composition.

But I should know better. Over and over again through the years I have read that the best way to write is to just sit down and do it. If you don’t feel like two hours of writing, do 15 minutes. That’s why this program I work with has a draft mode- what I write doesn’t immediately have to go to the Web. Just do it.

So I will try to do better. Just getting a new computer at work generates some enthusiasm. Things that took prohibitively long before now can be done so quickly. As a result, I have been enhancing and cleaning up the program and file cross-reference program I have written at work. I can track, in a nested fashion, what programs call what programs; and within a program I can click on a file name and get a file description or even display the file itself, scan the text for strings, and other neat stuff.  When it took well over an hour to generate the files necessary for the program, and now the files can be generated in under two minutes- that just gives you more of a feeling of power.

I was receiving the Web statistics on my various posts, and I found it very interesting that the articles that seemed to generate the most interest involved, in some fashion, freeform RPG. Even though I myself am not a big fan of it, it may be interesting to pursue that topic further in future posts, perhaps in a less dismissive way. I still believe in the validity of my arguments, but it may be worthwhile to analyze it to see why people are intrigued by it.

Programming in the Large

Saturday, September 27th, 2008

Before getting back to technical topics, I thought it worth a few lines to consider the programming environment and how it relates to programming technique.

When I was starting to program, the IBM Midrange (with the System/34 as its current representative) was pointed at small business. Its programming language, RPGII, was not viewed as a highly sophisticated tool. People without a Computer Science background could be expected to learn it without a great deal of fanfare. A common way to start was to begin as a computer operator and work your way up.

I suspect that those days are gone forever. The days when you would give the operator a manual and some programs to read are likely done. There are high expectations for programmers these days; if there are entry-level positions, they are well hidden; and those are probably reserved for those with at least some background in college-level courses.

The sophistication of the code also at times left something to be desired. More programmers were needed than could be generated by college, and so their techniques were not always clear. That was especially true with RPG II, which did not have structured operators (IF - ENDIF, etc.). Code was produced of the sort that positively gives me a headache today. A headache to maintain- but it worked.

And so we read today of sophisticated techniques derived from our study of other programming languages. Some are good, others not so good. But more and more sophistication is being demanded. And that can be a good thing.

But is zeal to pursue all these techniques a good thing? As always, the answer is, not always. If your needs are sophisticated, by all means, keep on pushing. But what if you don’t need these techniques? What if the business you support is profitable without them? Is it really a bad thing if you are not an early adopter?

The place I work now fits those criteria. It has been on the IBM midrange for over 30 years. Some of the programs are that old, too. Do you scrap code just because it’s “old”? No. You may try to improve it as time is available and the need arises, but first of all the business must be supported effectively. It would be a waste of time to try to shoehorn a new technique involving user spaces and message queues when it simply is not necessary. If some new technology will demonstrably advance the business, we get it.

So my job is not to be an early adopter, but to support the business, make improvements where I can, but not feel deprived if I am unable to employ some sexy new subroutine or program calling technique. The geek in me wants to try everything I read in the various technical forums, but the pragmatist in me tells me that I cannot do it. We just got a new machine with 13 times the space and over 20 times the speed of the old one; that ought to keep me interested for quite a while. We are connected to the Internet, but not directly; so many of the fancy new features of RPG that allow direct connect to the Internet simply are not needed. My co-worker does not have my RPG background, but I think he knows a lot and is learning more; his programming abilities go beyond RPG to the point that I can only envy them, not emulate them; I have neither the time nor the energy to do so. But his energy energizes me.

Updating code calls for patience. That is a virtue. I am not being paid so I can be entertained; I am being paid to create a positive business result for my employer; as long as I am constructive and keep on learning, I will be happy. I am not a small piece of a big puzzle; I am a big piece of a small one.

Multilingual?

Sunday, August 24th, 2008

Years ago, to talk about what language to use when you were going to write a program would be somewhat silly. You would use the language that came with the computer. Often, you would only have one language to work with - COBOL, RPG, BASIC, PL/I, C, or whatever. As microcomputers came on the scene, you still had few options beyond BASIC and Pascal, due to the small amounts of memory available. This, of course, changed as time went on, but if a shop had a particular language they worked with, they generally wanted to use that language only.

An interesting example of this was the situation a fellow RPG programmer once told me about. It was an engineering shop, apparently, but the only computer available was the IBM System /34 or System/36; the only language available on the machine was RPG. They had scientific calculations to do; so they got together with the programmer and described to him how sines, cosines, and suchlike things were calculated, and he proceeded to implement those calculations in RPG, which didn’t have much to work with in mathematical opcodes except ADD, SUB, MULT, DIV, and SQRT (square root). Apparently the results were acceptable.

Today, however, many more options are available. As AS/400 programmer now has RPG, COBOL (probably few installations have both, since they cover the same business programming ground), C, C++, Rexx, Java, and no doubt others. I have even come across a website that made available a Python interpreter for the iSeries (AS/400). If a person has a function for which he believes C provides a better alternative, he can, by implementing the proper subprocedure hooks, use that C function in his RPG IV program.

The problem of multiple languages, however, now is beginning to unfold. We now have the Internet, in which a whole new set of technologies are available: Java, Ruby on Rails, SOAP, AJAX, Python, Perl, Javascript, and others incorporating HTML, XML and other standard processes to get data out and available on the Internet. What is a programmer or company supposed to do?

If you are a PC programmer, the answer is clear- learn whatever you need to learn. Get a book, take a course, play with the new language and learn it. It is easier these days, because it is quite possible that the new language you wish to learn has some compiler and/or IDE (Integrated Development Environment) available free for download.

It is not so easy for the AS/400 programmer. Even mainframers needed to learn CICS, an external package, if they wanted to create interactive programs. However, on the System/34, System/36, System/38, and AS/400, the midrange had  no need to go outside the minicomputer framework to do normal processing. They had SDA(Screen Design Aid) to design screens, and the RPG program could interact with the “display files” created by SDA to handle interactive data entry. The screen was treated just like any other data file that the programmer could read.

Now, the demands of the marketplace are pushing on the IBM midrange. IBM has steadfastly refused to give the RPG programmer a tool that he could use to create Web access HTML. External tools have been produced within IBM, like CGIDEV2, but they have never been sponsored by IBM as a preferred tool; those who use it seem to be viewed almost as guerrilla warriors in a battle against… what?

Java was the first thing IBM gave us to access the Internet. They were really gung-ho on it. They  were so obtuse that they put ads in trade publications implying that if you didn’t set RPG aside and learn Java, you would end up flipping hamburgers at McDonald’s. (Hopefully, the person who designed that ad campaign was canned. But maybe he was only doing what he was told…)

But that didn’t work. Java was and is used by some adventurous and smart programmers, but for the most part it laid an egg in the AS/400 community. The learning curve was far too steep and long.

In the meantime, third-party software firms have stepped into the gap to provide solutions for the problem. But for those who don’t really want to be tied to an outside source, the problem still remains.

So now, IBM steps in and says the solution is EGL- another programming language. Even if it is easier than Java, why doesn’t IBM get the point? Why can’t they listen to the programmers who want natural access from RPG to the Internet instead of the Rube Goldberg apparatus they have been given? Why can’t they just mainstream CGIDEV2, or just create another, more direct access to create HTML? They even have an HTML keyword in DDS (the Data Description Specifications used to build data entry screens). If all they did was create a way to allow those HTML specifications to be built by SDA or something similar, it would be a step forward. The RPG programmer doesn’t need to produce HTML capable of showing an avatar of the customer running the 100 meter dash at Beijing. All the customer (or whoever) wants to do is enter data- he doesn’t need, and likely doesn’t want, anything too clever or sexy.

The real problem becomes that a company who needs to maintain its systems has to find programmers who know multiple languages, or it must find individuals who know both languages. If any other language is used but RPG, that code is going to have to be maintained by someone who knows the language. These individuals are hard to find. Non-RPGers don’t seem to care to come in and learn RPG-it is an “old” language. And RPGers have been spoiled too long in an environment that supplied all their language needs without going “outside” the AS/400 world. They want to do their job within the RPG framework, not go outside and be forced to use a new language. Aaron Bartell, a fine young RPG/Java programmer, talks about the problem of multiple languages in a blog post:

“We are reaching a point in the IT dept infrastructure where “framework evaluator/builder” is actually going to be a job description. I predict that in the next 5 to 8 years we are going to find that people will see the mess they created by adopting 5 different languages for different apps based on a variety of personnel hires, vs. sticking it out with whatever language they are most competent in (whether that be RPG, .NET, Java, EGL etc). “

So what can be done? I don’t know. Whether you talk about the RPG person reaching out, or the outsider reaching in, there is a problem. The outsider is prejudiced. The RPG programmer is getting older (and if he is my age, a little more tired; is tireder a word?), and unless his intellectual curiosity is high, he will not see the point in reaching out, especially if his shop is not reaching out to the Net or already have other personnel dedicated to that task.

It’s just a shame that IBM, for all their brain power, can’t give their AS/400 programming customers what they want- and I don’t mean another language.

May the FORCE be with you

Wednesday, July 16th, 2008

I admit it. I am beginning to get a case of writer’s block. What do I write about next?

I’ve been saving this subject for a while, but I could no longer resist using this headline. What does it have to do with programming?

It’s quite possible that even some RPG programmers are not aware that that you can FORCE RPG calculations. According to the RPG II manual, “The FORCE operation allows selection of the file from which the next record is read. The FORCE operation can be used for primary and secondary input and update files… Factor 2 in a FORCE operation identifies the the file from which the next record is read.”

The first time I ever saw this opcode used was in 1984, five years after I started programming. It was also the last time. I have NEVER seen it used in a working piece of code since then. My son’s textbook “RPGII, RPGIII, and RPG/400 with Business Applications” by Stanley E. Myers does not even show it in its index.

I don’t even remember how the code was used. I knew at the time. I examined the calculations to determine how the program worked, why it used the FORCE opcode, made the necessary changes, and went on with my life.

What makes this interesting is that you never hear a cry for the abandonment of the FORCE opcode. It is obviously centered around the RPG cycle, which of course is the spawn of Satan, and no self-respecting RPG programmer wants anything to do with it. “READ your file, don’t reCYCLE it,” is their battle cry. Yet FORCE escapes their notice. It is still in the RPGIV manual, so some nefarious, wizened old RPGII programmer (or original RPG programmer from the 1960’s!) might see a place where he could use it, and give new RPGIV programmers yet another reason to run away from their ILE terminals in panic at the sight. “I don’t understand…I don’t understand!!!!”

Or… NOT. If a real programmer sees an opcode he doesn’t understand, what will he do? He will look in the manual and find out what it’s all about. If he thinks it’s interesting he may say, “That’s neat” (or whatever catchphrase they use today to express approval), and perhaps thereafter see if he could use it too, perhaps finding out how it is best used. If not, he may ask, “Why would anyone use that opcode? Is that dumb or what?” (Choose your own phrase of disapproval.)

Anyone who warns “Don’t use the cycle”, or “Never use indicators”, or “Never use level breaks” are really insulting the intelligence of the ordinary RPG programmer. They are assuming that the grunt is too stupid to understand the evil he is getting himself into. If they then say that “modern” RPG programmers don’t do this or that, it becomes an ad hominem attack rather than a logical one. And if they say that new programmers won’t be able to understand this or that piece of code because of the technique or opcode used, they are wasting their breath.

New programmers will not reach out and accept RPG if it looks like Java or Pascal or C; they will just keep their Java or Pascal or C. RPG does not have to change its appearance in order to be successful, anymore than COBOL does. COBOL is still around and making itself available across the mainframe, midrange, and PC world. It has its weird keywords, too. If a piece of code is not wise to use, programmers will discover it- and avoid it.

So, when you’re programming, lighten up. Don’t worry, be happy. May the FORCE be with you. It won’t hurt you if you never use it.

Depending on the Kindness of Strangers

Wednesday, July 9th, 2008

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…)

And the #1 reason why freeform RPG is best is:

Saturday, June 28th, 2008

#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…)

More on the virtues of Freeform RPG

Saturday, June 21st, 2008

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.

You don’t write compilers in COBOL

Sunday, June 15th, 2008

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.