RPG and Programming

In considering the craft of programming, sometimes not enough attention is paid to the people you program with. Of course, if you program alone, this is not an issue, but it raises the issue of who is going to keep you in line.

To give a quick example: During the last couple of days, I wrote a little Visual Basic program to facilitate access to an organized group of mp3 files- more specifically, oral readings of Bible books. To make the routine somewhat generic, I put the location of the data in a record of a data file, and the next record in the file was of the location of the program used to read the data- in this case, Media Player. I would then use these pieces of information to build the command VB would use to play the mp3 files. It worked on my computer just fine, and I copied those locations and reentered them in a data file on the system the program was intended for. It didn’t work. But why?

I came back home to my computer and puzzled over it awhile. I then decided to go lay on the living room couch to relax. About ten minutes later, I bounced off the couch. “You idiot!” I said to myself. I realized that the drive location I specified was G:\Bible. This was fine for my home computer, but my destination computer only had a drive C. I went back and corrected it, and all was well.

This illustrates the value of being able to work with others. I didn’t discover the solution until I had disconnected my mind from the problem. In effect, I had created a new, objective observer to critique my code and the situation. The problem might have been easier to solve if I had had another pair of eyes to look at it, instead of having to clone a mental image of myself for the purpose.

Thinking of that reminds me of a situation of my earlier career (not sure if I already blogged about this or not). I had a problem with a piece of code. I sweated over it for hours. I finally decided to share it with my co-worker, a more experienced programmer. I started to describe my program as I spoke to him: “First I want to do this…..(Description) And then it’s supposed to do this….. (More description) And then I do this… And….Ohhhhhh Boyyyyyyy.” The solution to the problem leaped out at me, and my partner never had to say a word.

I am normally not a fan of having two programmers work together closely while coding, but sometimes having one or two people around to bounce around ideas can help. Once a group gets above three or four, the benefits of having a group seem to waste away. Too much clutter. If you can get a few very good programmers together, I think you can write almost anything. If you get a lot of programmers together, they seem to get in the way of each other. Doubling the number of programmers does not get double the work done. Of course, much better programmers than I discovered that fact a long time ago.

I think I like the group I am in better than any other group I have ever worked with. The oldest one in terms of experience is about my age, but he started when he came out of college, I believe. I think his first language was Algol. (I’m serious.) He has also worked the longest with my current employer, and he has the deepest understanding of the current system. The other programmer is a bit younger than me, but he worked for this employer when he was young as a computer operator, left for about 25 years, then came back to program RPG. Both of them have degrees, one of them with a Master’s in engineering, I believe. (Not sure what kind of engineering.)

Their styles are quite different. The older one is quite methodical, and he navigates the AS/400 with lightning-fast use of the menus. The younger one loves the AS/400, but he is definitely a PC guy. He has enhanced a PC programmer’s editor until he can cut, slice, and dice any data or program from the AS/400 he wants to, any way he wants to. He’s comfortable with Java and Rexx too, which makes his choice of programming options that much greater. I thought I had a quick mind until I met him; now I know I’m hopelessly slow. He is not afraid to make mistakes-if he makes a mistake, he fixes it -  while fear of making mistakes is my biggest fear. The only claim I have to superiority over them is my greater experience with RPGIV - but as fast as they can learn, that advantage will not last indefinitely.

And the best part is, we value each others’ abilities. Blend all this with management that points us in the right direction without being intrusive and lets us brainstorm and try fresh uses of our programming resources, and it would be hard to find a better programming group or programming environment.

I am still trying to push myself into actually learning to put the programming language Oberon-2 into practice in an actual project. And I’m still dancing around the periphery of my programming course.

Much of the early portion of the book “Oberon-2 Programming With Windows” concerns itself with actually setting up and getting acquainted with the programming environment. An interesting aspect of this environment is that it is not exactly like the environment Niklaus Wirth created when he created the Oberon language to enable the creation of the Oberon operating system back in the 1980s. The original Oberon system did not require that modules be linked explicitly to a program. They are somewhat independent entities. How this can be so is beyond the scope of this post; but in this implementation of Oberon for Windows named Pow!, one module has to be designated as the main module, which then can be explicitly linked to other modules.

The idea of modules being integrated into a whole is hardly unique to Oberon, of course. The idea of “top-down” design goes back at least to the 1970s, where it was felt that the best way to handle complicated tasks is by breaking them down into less complicated tasks, which could also be further broken down into simpler tasks of simple resolution.

For a general purpose language, this is truly an elegant concept.

Perhaps this is where we see the main difference between elegant block structured languages and the old business languages like Cobol and RPG. I will speak of RPG, since that is what I am most familiar with. RPG IV is what might be considered a “large” language. Everything you might ever want to do in business programming is part of RPG; and when you read discussions of how RPG might be improved, you will read suggestions of features that should be ADDED to the language. You will never hear talk of modules or “libraries” or even “service programs” being able to be referenced by the language. New features must be PART of the language; and if they are implemented, they simply make the language bigger and, in most cases, more complicated.

And so we see this world-view even in the structure of RPG programs. Usually, an RPG program does not consist of a few program or procedure calls in a relatively short mainline. It usually consists of a substantial mainline with occasional calls to subroutines or procedures. There is relatively little need or use of the top-down paradigm, or conceptual model. It is possible to do it in RPG, but the very layout of the language does not encourage it. For example, I recall being amused years ago by an RPG program that had only one one line in its detail calculations; it did all its work in a subroutine named DETAIL, which was called by the calculation   EXSR    DETAIL. The very phrase “service program”, used today to refer to a collection of often-used routines into one module, suggests a servant pressed into duty of a superior routine, rather than a coequal partner in the main processing. The name “subroutine” has the same connotation, even if the subroutines do the bulk of the processing. They are subordinate, called by the main “detail” routine.

As RPG is currently constituted, I would consider this the most effective way of using the language. For example, there is the concept that all file handling operations should be consigned to a service program, which would then handle accessing, inserting, deleting, and updating records in a given file. I know I’ve seen the concept recommended, though I can’t give specific  examples offhand. But when  file handling is so easy in RPG, why bother with a service program when you can do it directly?   ACCT#    CHAIN   MASTER.

So I’m up against a wall of habit and preconceived ideas as I continue to try to expand my horizons, and perhaps my effectiveness, by learning a language built on new concepts and that can be completely described (in the official report on the language) in 16 pages of normally spaced text. Just for comparison, the report for C++ is 740 pages in length. (I am already acquainted with BASIC.)  If I can’t learn Oberon, there’s not much point in trying others.

In a blog post on my son’s blog, I ruminated on helping young people to learn to program and what might be a good place to begin learning programming. At the end of the article, I suggested Oberon-2, a language created by Niklaus Wirth (creator of Pascal and Modula-2) and an associate. At the same time, I bemoaned the fact that I seemed to be unable to learn new languages, perhaps because of burnout or fatigue, perhaps lack of time, or even lack of a suitable project.

I have just about concluded that it is time to put up or shut up. I have a compiler, I have a book, and I have a project. It is time for me to go ahead and exercise some initiative and learn the language.

But perhaps you wonder why Oberon-2? Why not Java, which is also on the AS/400? I have commented on the steep learning curve. I have attempted Java tutorials; I have found them to be of a most forbidding nature. I don’t know if Java is supposed to be a “small” language or a “large” one; all I know is that one look at the documentation (see how long it takes you to scroll through the class list) makes me want to cringe. Of course, with any language, you usually use only subset of a language in your day-to-day programming; the problem here is finding what your subset consists of.

Why Oberon-2? It is object-oriented programming without the gobbledygook. A “method” is a procedure. A “class” is a record type. A variable of a record is an “object” or an “instance” of a “class”. A procedure call is essentially the same as “passing a message to an object”. I find the unquoted terms in the previous sentences more comprehensible than the corresponding terminology (in quotes) that has been perpetuated for the Java and C++ and Smalltalk environment. And it does not appear that it will take that long to learn how to write useful code; that is important for me.

So I propose to begin learning this language, and from time to time report on my progress. Knowing that at least a few people might be observing may also exert a certain social pressure to press on.

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.

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.

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.

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

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?