RPG and Programming

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.

For the uninitiated, indicators are essentially Boolean variables which, until recently were defined automatically by the RPG compiler. (With RPGIV, you can now define your own named indicators. See this article for details.)

The system defined indicators are named by the digits 01-99, which may be defined by the programmer, L1-L9 to define level breaks(where changes in input data are automatically detected by the program), MR (used when matching file reads with similar keys), halt indicators H1-H9 to halt the program when an error occurs, and overflow indicators OA-OG and OV to flag when a printout is at end of page and ready to go to the next.

The trend today is to totally swear off indicator usage in RPG programs. This is understandable. Misused indicators have been the cause of many programmer headaches or worse. You’ve never lived until you’ve tried to get your head around a 10000 line RPG program that uses all 99 numbered indicators in calculations, and as many as possible in the output. You find yourself frantically turning from line 2000 to line 8763, trying to find out what on earth is the significance of indicator 56, or when it is true that indicators 45, 65, and 67 are on and 33 and 89 are off, with even fields in the output conditioned by up to three indicators.

Or how about these calculations and output?

 
C           X             COMP 25                   253746
C  N25N37   Y             COMP 36                   161514
C   25 46 16Z             COMP 83                   1726
C   26 16 25CUST#         CHAINCSTMST               12
OCUSTMSTRE         17 16        OUTPUT
O                  25 27 46     FIELD1   45
O                  37 15 46     FIELD1   50
O                  14 27 46     FIELD1   45
O                        12              57 'NOT ON FILE' 

There’s just too much going on in one line of code.
So when people want to get rid of indicators entirely, you can understand. But do such programs prove the point that indicators must be gotten rid of at all costs?
Well, not necessarily. It depends……

Philosophy is such a pretentious word. Perhaps I should call it my way of thinking about programming.

If I am not programming for my own use, I want to do what the user wants and needs. Of course, sometimes the user does not really know what he wants, and I must help him try to figure it out. But I do not take the attitude that I know better than him what is good for him.

As for technique, I try to be like the physician- at least do no harm. I try to be careful and not introduce careless errors. And I desk check as much as I can. The earlier you catch errors in the process, the better.

But perhaps I should get to areas where I might differ from a great number of other RPG programmers. In RPG, due to language evolution, there are often many ways of doing the same thing. Unless doing so will only perpetuate and intensify confusion, I prefer to maintain a program using code in the style it is written. That is not a hard and fast rule, but a general principle. If it is in RPGIII style, it will usually continue to be so, even if I have migrated it to RPGIV. I might enhance it with code unique to RPGIV, but I will not often consider it my duty to go beyond my maintenance function, rip the program apart and rewrite it.

My consideration of coding choices revolves about effectiveness. I will use whatever will create smooth, elegant code, whether it is considered new, or “old” and “archaic”. If an “old” technique works better, I will use it rather than some solution cobbled together from “new” techniques. If the new one is better, I will use it. It is all about what works most elegantly and clearly. Terseness is not the only goal. The time it takes to key in a program is the least time-consuming part of programming. If terseness, the keying of the fewest characters on the keyboard, were the goal, I would have given up RPG long ago and learned APL.

Too often I feel, programmers think that “change is good”, so they feel the urge to update old code, even if it is working without error at present. Programmers also seem to be easily swayed by what is the newest fashion in programming. I am not. To condemn a programming technique as being not “modern” is the grossest form of condescension. Remember, Adolf Hitler was at one time the “newest” ruler of Germany, was a popular choice, and represented vast “change” in the political landscape. That “change” was not good for Germany or the world. On a less cosmic level, change in programming technique is not necessarily good. An opcode is not good merely because it is a part of a set of new opcodes or BIFs (built-in functions). Each one must withstand inspection to make sure it is worth using in any given situation.

And sometimes we seem to forget that any RPG installation that existed before the advent of RPGIV is going to have “old-styled” code; the older the shop, the older the code. It is pointless to try to hide this fact from new RPG programmers; it is useless and self-defeating to try to hide this code from the new programmer or let him believe it does not exist. Unless you are part of a software company and have free rein to make any changes you please, you will be maintaining old code at some point.

How these principles apply in my coding technique will be made more clear as we go on this blog. There may be other ideas that also come into play. For now let the above suffice.