RPG and Programming

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.

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

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?

I was once sent to a client to take care of some fairly modest modifications to some RPG programs on their System/34. As I went about making changes on a certain report program, I concerned myself with the requested changes, not paying much attention to how the program performed its main processing. As I submitted the program changes for test, an employee said to me that I should expect it to run for about 2 or 3 hours. Having looked lightly at the processing, and being acquainted with the 34’s processing speed and the size of the file being processed, I smiled inside. “More like 15 or 20 minutes, I think”, I said to myself.

To my surprise, it in fact did take around 2 ½ hours. I was anxious to find out why I was so wrong, and what I found disgusted me, and for the first time made me angry about the work of another programmer.

The file being processed was a detail file. That is, it was part of a file setup common in data processing where the line items in, for example, an invoice, are stored in a separate file from the general information about the invoice.

Let us suppose that the invoice “header” has a key of invoice number – the file is organized to be read in invoice number order. For our example, let us suppose the invoice number is 123456. In later versions of RPG, you could define file keys from fields physically separate from one another in the file; but this was RPGII on the System/34, and the key data had to be all together. In this case the key to the “detail” file was the invoice number followed by a 3-digit sequence number. So the detail keys for invoice 123456 could range from 123456000 through 123456999, though in practice the 000 record was not usually used (since the files were no doubt designed by business people, who would think starting to count with 0 was nonsense ).

Now, the customary way to read these records was to set lower limits (SETLL) using the invoice number and the lowest possible key (123456000), determining the highest possible key (123456999), then READing the file until you either reached end of file or the key of the record read was more than 123456999. Not having looked closely at the code before, I had assumed that was the way it was done. Since you would very seldom find an invoice with 999 line items, this would be the logical way to do it.

But this was not the way the programmer did it. She instead used a separate counter from 1 to 999; for every number from 1 to 999, she moved that number to the end of the key (getting 123456001, 123456002,123456003, etc.) and performed a random-access CHAIN to the file, using the data if the access was successful. So, if there were 4 detail records for the invoice, she would have 4 successful reads and 995 unsuccessful reads, instead of 4 successful to 1 unsuccessful the normal way. The program was spending over 99% of its time accessing the disk looking for records that didn’t exist!

What made the matter worse was that this logic was replicated in quite a few of their other major programs. Now, I’m not normally a person who likes to rock the boat, but this was too much for me. I went to my supervisor there, explained the situation and asked for permission to change these programs to do it the right way. Permission was granted, and I hunted down the other programs and modified the read routine in all of them to do it properly. And yes, they did complete in 15-20 minutes, just as I thought they should.

Unfortunately, this was too little too late. I found other areas where the programs, though giving correct results, were very poorly designed. The proof of the damage this programmer and others had done to this firm was evident in the fact that, at the time I came to that firm, they were in the process of moving their processing to another, non-IBM minicomputer using another dialect of RPG because it was deemed that the System/34 just didn’t cut the mustard. It was too slow.

This may be an extreme example. Normally, I don’t sweat performance too much, though even today I think programs are more bloated than they need to be. (I once compiled an RPGIV program with only 1 line: eval *inlr=*on. Its size was around 80K.) But bad programming can really have a bad effect.

I prefer that programs be clear and understandable, so that they can be more readily maintainable; performance can be somewhat secondary. I think that reducing disk access is the key to most performance issues. I really don’t worry about whether or not one opcode is 50 nanoseconds faster than another. Talk about a few trillion nanoseconds here and there and we’re talking some real time.

But sometimes you do have to stand up for a certain standard of performance. Unfortunately, in that company, quality control came in a little too late. Perhaps it was a human relations issue. While I was at that company, they talked about how much they liked that programmer as a person. She must have been a real charmer. Evidently, they liked her so much that they accepted whatever excuse she gave for a report run that took 2.5 hours to produce a report. Apparently, she had no intellectual curiosity to try to figure out why it ran so long. That, to me, was her cardinal sin- a lack of intellectual curiosity, a lack of desire to do what she could to improve her product. Her report produced correct results, but she could have done it right, she could have done it better.

I find I’m rambling here, in search of a point. Perhaps it’s just that quality is the important thing. Accuracy and clarity in the design. The ability to discern when something just isn’t right and know how to fix it. Be willing, whether a user or a programmer, to speak up whenever you see something that isn’t quite right, and talk to the people who can do something about it – don’t just vent to your fellow programmers or users. If a user, tell the programmer when you think his program isn’t working right, and show him how. If his pride gets hurt, so be it.

And, in harmony with what may be a recurring theme here, don’t worry about doing it the newest way; just do it the best way. Just do it right. That may not be easy; others may think another way of doing something is better (more right). If they are correct, then be willing to change.

And keep your mind open for change that is not the result of someone prodding you, but of you prodding yourself.

Back around 1980 or so, I read an article or two by Dick Eagleson in an IBM minicomputer trade publication about the (then) relatively new concepts of structured programming. I believe it was before the System/38 came out, so he explained how to perform sequence, selection (IF-THEN-ELSE-END; CASE;and so on), and iteration (DO-ENDDO-DO WHILE, etc.) in the context of pre-System/36 RPGII, where all you had to work with was COMP and GOTO and TAG. (In this article, he also declared his Law of Software Strangeness: Any code you write and don’t look at for six months may as well have been written by someone else when you look at it again.)

In this article, he also declared that just because IBM provided 99 numbered indicators to use, it didn’t mean that you had to see how many you could stuff into any given program! It was not a revelation, because it was so obvious; but the implications were grand. You did not have to use all the indicators that come to mind in your programs. The need for indicator complexity was nonexistent; do it the structured way.

To give an example, suppose you wanted to convey this RPGIV concept:

     C                   IF        (X>5 and Y<3 and Z=9)
     C                   DOU       X<5 or Y>3
     C**  Some code that changes the values of X or Y
     C                   ENDDO
     C                   ENDIF

This is how you could render it in RPGII:

     C           X         COMP 5                    25
     C   25      Y         COMP 3                      25
     C   25      Z         COMP 9                        25
     C  N25                GOTO EIF001
     C           LUP001    TAG
     C* SOME CODE CHANGING X OR Y
     C           X         COMP 5                      25
     C  N25      Y         COMP 3                    25
     C  N25                GOTO LUP001
     C           EIF001    TAG            

This new way of thinking changed the way I programmed from then on. While I did not swear off indicators as I learned RPG400 and RPGIV, I made sure that my code would be as succinct as possible, using as few indicators as possible. At the same time, I was not afraid of using them or overly concerned about getting rid of them.

Much of the dislike for indicators seems to be based on the fact that they are not self-defining like a field name is (CUSTBAL, for instance meaning Customer Balance). If you set on indicator 89 for an unsuccessful CHAIN(random file access) operation, and you continue on into your calculations without referring to indicator 89 in your calculations, you tend to lose track of the significance of indicator 89. That is true. But immediately after the CHAIN, you DO know the significance of indicator 89. Do whatever you need to do with it-change the course of your processing, put out an error message, or whatever- then FORGET about indicator 89. If you really need to save the result of the CHAIN, set a field to Y or N based on the results (or in RPGIV, save it in a named indicator variable). Go ahead and use 89 somewhere else, if the spirit moves you.

Other examples could be given. Record identification indicators can be defined by the program to identify when a particular file is read. Especially if you are dealing with Input Primary and Input Secondary files (where entire files are read from beginning to end with no need for a READ calculation), these indicators are self-documenting (unless, if you’re foolish, you change their settings in calculations).

Now, do I use an indicator when doing a CHAIN operation? No, I don’t; I use the %FOUND BIF (built-in function) to test whether a chain was successful. But I have no problem with others using CHAIN with an indicator. At a previous employer, they were considering coding standards, and they wanted to mandate the use of BIFs like %FOUND. Another programmer pointed out that when you use %FOUND, when running a program in debug mode, the BIF does not give immediate feedback on the success of the CHAIN; using CHAIN with an indicator gives you immediate feedback. I had never thought of that; and I can see that as a reason why a programmer should indeed be permitted to use an indicator in this situation, if he deems it appropriate.

So I have no problem with indicators as such; only when they are used badly, as I showed in my previous post. And I think that RPG gurus and others who have a hissy fit when indicators are used (in a proper way) should just calm down, relax, get another cup of coffee and find something worth worrying about.

My name is Curtis Barron, and I am a computer programmer.

Almost 30 years ago, I began to learn about computers and to program them using the business language RPGII. I was part of a group of people being taught by the manager of an IBM System 3, Model 10 minicomputer installation. The school was in his kitchen. We got the appropriate textbook. (I believe it was by Shelly and Cashman.) I was the only one of the group who actually got a job programming as a result of that class. My teacher hired me as a programmer at his company one day a week; providentially, only about a month before he left the company. I came on board full time in December, as a combination programmer and accounts payable clerk. I had gotten my toe in the door; I went in and never looked back. I have proceeded to learn all the succeeding new dialects of RPG- RPGIII, RPG/400, and RPGIV.

My attention has been focused, by my job, on RPG; however, I have an intense curiosity about other languages, old and new. I have tried to learn some of them, but I have usually been stymied by the fact that I had no particular project to use them on- I find it difficult to learn them without a particular goal. I have learned the following computer languages well enough to write “production” code - code that would be used by someone else - in Apple BASIC, GWBASIC (that came with my Tandy 1000), Visual BASIC, and a few routines in Rexx. I was rather proud of the GWBASIC effort; I built data entry screens in the style of the AS/400, instead of line-at-a-time data entry, having the user press enter to go from field to field and processing all the data when the last field was entered.

Besides religious activities, I enjoy reading and being with my family. My favorite authors are Jane Austen and James Herriot. I have contributed a number of comments to Austenblog, a Jane Austen discussion group.

I intend to write on my experiences and feelings about RPG - promoting it as a valuable computer language, discussing my ideas on programming technique and on programming in general. When I really get underway, which should be in just a couple of days, I hope you will find it interesting enough to come back and read again.

Comments are encouraged and welcomed.