RPG and Programming

Being an old baby-boomer brings one a certain perspective to programming. Some my age started way back in the 60’s with their COBOL, assembler, and Fortran. Back in the 60’s, I had never knowingly come within miles of an actual computer. And being of a distinctly lower-class (economically, that is) background, I found computers interesting, but there was little chance of them becoming  the center of my life. Of course, the only lives centered around computers then were the programmers and manufacturers of them. Now, of course, anyone who wants to can program one. Even doing an Excel spreadsheet is programming of a sort.

But is being a programmer automatically a good thing? I would submit that whether you are a good programmer is determined by more than your ability to program. I believe it is also determined by what you program.

Now, we will grant that being a programmer of business programs is not the most exciting of occupations. But at least the program, if it is written to perform effectively in its context, may be considered to perform a useful service. That is what programs were originally designed to do. (Some might quibble that ENIAC, arguably the first electronic computer, was prompted by the need to perform calculations of artillery shell trajectories; it was useful, but some would point it out as another use of science in the service of warfare (see atomic bomb), which they would consider a dubious use of science.)

But is all programming good? I submit that the answer is no, even if it performs as designed. Back in 1982 there was a game called “Custer’s Revenge”. The point of the game was a naked General Custer “running across a desert obstacle course to reach and ravage an Indian maiden”. (August 30, 1982, issue of Advertising Age) Was there any redeeming social value in that game? I think not. Since then the computer graphics have improved, but from various news reports and reviews of computer games, I have concluded that the content of many games has not improved - only deteriorated, along with the general state of society. Sadly programmers, for all their cleverness and intelligence, have contributed to the moral decline of society in general.

And the programming need not be lascivious in nature to have a negative effect. Gratuitous violence hardens young people to the significance of the real thing, the hurtfulness and pain that violence in reality causes. Also,  many video games are designed to be played for hours on end, sometimes over a period of days. Is this the kind of thing that young people and adolescents need? About the only time such a self-centered pursuit would be good would be if the neighborhood was so bad that it would be dangerous to go outside.

Perhaps that is why I cringe a little when I realize that there are college degrees in videogame programming, here for example. There may be good uses for video games, but one suspects that educational video games are not where the big bucks are. How many young programmers will go into video game programming because of the good it will do for mankind? Probably not many.

Hopefully, if you are starting to program now, you want to learn for the fun of it and perhaps the intellectual challenge. Once you gain the skills, for the good of all - including yourself- be careful about what you choose to program.

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

#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?

Late last week I prepared to write a subprocedure for a program I am currently working on. This was significant because, though subprocedures are recommended as a highly significant new way of modularizing our programming (subdividing the programs into manageable procedures rather than the monolithic program model of standard RPG), I had never written one myself, though I had maintained a few. Modularization is common to almost all modern computer languages except RPG. That is, until several years ago when subprocedures were added to RPGIV.

I had taken an introductory course in ILE RPG several years ago and learned about using subprocedures; but since that time, I had neither opportunity or (I confess) inclination to use them. I could see no burning reason to use them, for reasons I shall explain later.

But in this particular case, it seemed an opportune time to try it. The subprocedure would be based upon another program already written by someone else. Without going too deeply into the details, the program determined the status of a particular spooled file; on the basis of this determination, the program performed some other tasks and updated some files. I wanted to use the front portion of this program and use the status determined for another purpose and not update those files. To that end, I cloned the program, performed an amputation on the clone; with that and a little bit of plastic surgery, I had the processing in place that I wanted.

Most of the subprocedures that I had read about did not do any file processing; they were straight calculations. This program used several files, but I did not foresee that as a problem, since I understood that files could be part of subprocedures. I had done my research, and I had printed out what I considered a fine tutorial by Jon Paris that I had found on the Internet.

In line with some of the recommendations, I intended to use this as a separate module that would eventually be pulled together with my original program that would use my new module. I put NOMAIN in the Header specification to indicate that this new module was not a callable program by itself and would not use the RPG cycle. The process I was intending to implement needed to run as efficiently as possible, and the module would not need the cycle anyway.

So with high expectations I began to put together my sub-procedure. The tutorial mentioned above shows quite nicely how to do it, so I will not belabor the general process here. I fully expected to have some problems; you have to expect that sort of thing when you’re trying something for the first time.

So, how did it go?

As expected, I had all sorts of problems, mostly centered around where to put the Input specifications in the subprocedure. Finally, this morning, I figured out what I was doing wrong. I got the subprocedure module to compile, and I am now testing the main program. I seem to be getting more than satisfactory performance, which is what I was aiming for, along with some practice of how it was done.

However, while some think that subprocedures in RPG programs are the greatest thing since sliced bread, I simply don’t agree. Even those who like them admit that creating and using a subprocedure is more of a song-and-dance than a dynamic program CALL is. I had to compile the calling portion as a module, the subprocedure as a module, then run CRTPGM to link the two together. Additional code is also needed, in the form of prototypes and prototype interface definitions. I think a number of different factors might determine whether to use subroutines, dynamic CALLs, or prototyped CALLPs or prototyped function-like expressions. The “modern” way to do it may not necessarily be the best way.

I intend to discuss subprocedures in more depth in another post, as well as that hallmark of “modern” RPG, freeform RPG. In the meantime, back at the office, I will make the program work tomorrow.

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.

Charlie Massoglia, a well-known author in RPG circles, as well as the owner of his own consulting firm and past president of COMMON (a prominent IBM midrange user group) once wrote a series of articles introducing RPGIV to the world. In one of them he said: “Contrary to conventional wisdom, our shop does use control level indicators for reports since there is no easier way to produce subtotals and we have found negligible performance differences between input primary and full procedural files.” He acknowledged that he was likely a minority holder of the opinion when he followed the above remark and prefaced further discussion by saying, “Without getting into a debate about whether or not control level indicators should be used…”

A discussion of control breaks (or level breaks) almost always ends up in controversy. Even though control breaks, as part of the RPG cycle, have been part of the language, and very commonly used from the start, many RPG programmers don’t have a clue as to how the cycle functions, or even any reason why a programmer would even want it. It often goes beyond a intellectual discussion of merits and demerits of automatic level break handling by the cycle. Most RPG authorities would say that the less said about them the better. Bob Cozzi, an RPG authority, probably says that the “modern” RPG programmer does not use the cycle, though I haven’t looked at his classic “The Modern RPG Language” in a while, so I can’t be sure.

The divide seems to be at the System/38. If a programmer got his initial experience using RPGII on the System/3, System/34 or System/36, in my observation they have absolutely no problem understanding the RPG cycle and think handling level breaks using the cycle is the obvious way to go; If they started their RPG experience with RPG with RPGIII on the System/38 or RPG/400 or RPG IV on the AS/400, the cycle is mind-boggling and those who use it are demented.

Forum discussions of the RPG cycle often deteriorate into name-calling, generally at the expense of the old guard, who should just retire so the real programmers can fix what they did. It becomes almost a religious issue. Once I just brought up to someone the subject of level breaks using the cycle, not even arguing in favor of it, and by his tone of voice in reaction you would have thought I was suggesting I wanted forcible carnal knowledge of his sister.

I find that some authors will admit in forum entries that RPG using the cycle makes sense at least in some circumstances, even though their full blown books will consign discussion of it to an appendix entry.

Level breaks, as described above, are linked tightly to the RPG cycle. Until recently, all RPG programs use the RPG cycle automatically; however, most “modern” RPG programs tend to try to make believe that the cycle doesn’t exist. The one who wants to ignore the cycle will use a repeated READ or READE statement to read a file or a subset of it. The one who uses the cycle does not need to do this, assuming his main focus is reading a single file (or multiple files) from start to finish. (This programmer may use READ or CHAIN opcodes to read files subsidiary to the main file being read.).

For this reason, I will reserve a further discussion of level breaks until I discuss the RPG cycle. This will involve an interesting discussion of programmer psychology and why programmers sometimes reject useful techniques for the sake of an ideology.