Programming and Thinking
I have read on more than a few occasions that it is important what programming language that you choose to write programs in, because it has a bearing on how you think about programming problems. An RPG programmer will likely approach a report program with an entirely different view than a C programmer. In this case, the RPG programmer would likely be able to take a more direct approach to the program than the C programmer, who would likely need to pay more attention to how to express the precise report layout. On the other hand, while compilers are written in C, I shudder to think of what a compiler written in RPG might look like. And can you imagine an RPG compiler written in RPG? Niklaus Wirth’s Oberon compiler was written in Oberon. Don’t ask me how.
This subject came to mind as I contemplated some of the indicator-laden code written for our system over the past 35 or so years- some original code, some heavily modified and added to over the years.
The code, of course, is hard to follow. It may have been easier to write. It’s easy to write code conditioned on one or two indicators; then a condition or two must be tested for, and all of a sudden you are slowly spun into a swirling maelstrom of competing indicators, repeating your original two as you go down the page and see how many permutations of the other three can be devised, how many of each permutation are used before the combination changes, with an occasional sixth or seventh indicator thrown in for good measure. And of course the output is conditioned on each of those permutations, with individual fields based on further combinations of those and others outside that group.
As I said, some of that code was written in the 70’s, before structured concepts began to be widely used, and certainly before they were applied to RPG. I learned how to do this even before concepts like IF-THEN-ELSE-END were even part of RPG. (See my 5/10/08 post “The Good(Indicators Part 2)”.) Evidently, not too many people read the same magazine articles I did, and even fewer implemented the concepts before IBM began to implement them in RPGIII for the System/38.
What is sad is that even after the concepts were made available, they were not well implemented in our shop. Maintenance of the old code was hard enough, but the more they modified the programs in the style they were written-whether RPGII or RPGIII- the harder they became to follow. And when RPGIV came out in the mid-90s, it was effectively ignored. I think I wrote the first RPGIV programs on our system in 2007.
When you are unwilling to implement new programming ideas, it makes the maintenance task even harder. If, when RPGIV came out, they had begun tweaking the code to make it easier to read, it would be easier to follow now; and sometimes relatively trivial tasks would not be attempted simply because the techniques that made them simple were ignored. By maintaining the old mindset, a lot of time that could have been used progressively was wasted.
A big example of this comes in the area of string handling and editing of numeric data. Of course, the handling of string data on a character-by-character basis has to be done in RPGII, RPGIII, and RPG400 by pushing them into arrays and manipulating them as individual array elements. Formatting of numeric values into, say, dollars and cents, must be done by means of edit codes and edit words, which are character patterns that define the look of a number.
An example: On a line of a subfile of a transaction history, the two numbers to be displayed could be dollar amounts (12345.67) or interest rates (123.4567). In generating the subfile, I found that you could not format the numbers in one of two different ways(using edit words), depending on whether it was to be dollars and cents or a percentage rate. This was unacceptable to the the screen format compiler; you had to pick one or the other, and the dollars and cents version was selected. This, of course, then has to be translated mentally by those who use the screen.
The solution, then, would be to output a value that could be expressed in two different ways. What I did a few years ago, before RPGIV was available, was to write the value to a temporary file (just as I would to a print file), then chain to that file and pull out the newly formatted value for use. To format a date, I would write a date as ‘03/08/09′ to a file, then access that 8-character string. Somewhat of a kludge, but it would work. There are no doubt other ways to do this in RPGII or RPGIII, but they are still likely to be kludges.
But in RPGIV, it becomes a piece of cake: Suppose you have a 7 digit numeric field NBR. You can then define a 10-character field FIELD and two edit words as constants: DOLLARS ‘ , 0. ‘ and PCT ‘ 0. ‘. You then say
IF (dollar value) EVAL FIELD=%editw(NBR:DOLLARS)
ELSE
EVAL FIELD=%EDITW(NBR:PCT)
ENDIF
This FIELD is the value that then goes into the subfile. It was very easy to test, implement, and put into production. The users were very pleased.
Now, this solution that took me only a very short time could have been done a long time ago, but it wasn’t. The possible solutions, based on the way of thinking engendered by the old programming language (RPGII) made a simple correction a daunting task, and evidently it was felt it would take too long to implement.
Now, this was not intended necessarily to be self-congratulating. It was meant to show that not being willing to learn new and better things can have longlasting consequences. More to the point, being too deeply immersed in a certain programming linguistic style can cause one to avoid ideas that could be better both for you and for your users. In an environment like this, it may not be practical to choose between C and RPG; but while choosing new stuff (change) may not always be better, it CAN be.