Archive for the ‘Control (level) breaks’ Category

To Amaze the Whole Room

Wednesday, July 4th, 2012

In my favorite novel, “Pride and Prejudice”, Elizabeth Bennet says archly to Darcy, “I have always seen a great similarity in the turn of our minds. We are each of an unsocial, taciturn disposition, unwilling to speak, unless we expect to say something that will amaze the whole room, and be handed down to posterity with all the eclat of a proverb.”

Perhaps a reason similar to this is why I have not been as faithful to this blog as I ought to be. I feel like I need to say something IMPORTANT. And INTERESTING. Sometimes, no topic seems important enough to grip my interest until I get home and go through all the other stuff a head of the house does after work, eat dinner and rest in front of the TV for a short time. (Hmm.. I’m beginning to sense a pattern here.) A little topic may come to mind at work, but by the time I get home, it’s gone. Even if I write it down, I then forget to look at the piece of paper.

The day-to-day life of a programmer is not really that interesting, unless he is absorbed in a project or problem.

The life of a maintenance programmer can be tedious when his mind is not fully occupied. I have a number of projects in process, but nearly all of them are at a stopping point. Not done, but at a point where my next step waits on the actions of another, usually a user.

There are no issues of cosmic importance to be resolved. I am writing new code in freeform RPG. I am not messing with the structure of old programs just to improve them. I convert them to RPGIV when I make modifications to them, but usually I do not attempt to get them all the way to freeform; with all the indicators dancing around in them, freeform usually ends up being an even worse mess than what I start with.

There are old fashioned date routines in many of the programs. I do not touch them unless the modifications have to do directly with date calculation. The basic calculations can be easily replaced with my date functions based on IBM APIs; but they don’t always plug in neatly, which means intensive testing that I don’t want to do when I only want to change a heading or tweak one or two lines of code.

There are two RPG programmers in our shop. We both code in freeform, so there are no areas of conflict there that would make life in our shop exciting.

Somehow, the areas of contention with other programmers (inhouse or online) like control break processing seem rather dull. I do what I want and no one is around to argue with me. (My wife gets after me because it sometimes seems like I like to argue..)

Of course, as I press on into my mid-60‘s, I suppose that decreased conflict is probably not a bad thing. Anything can happen, of course, but I see little likelihood of my job situation changing before I retire in another 10 or 15 years. :-)

But maybe if I picked up on the little ideas that pop up during the day and run with them at night, I could be more productive. Maybe if I had a better way of holding onto them. Maybe if I could get a little spiral notebook.. or a netbook… or a tablet…

A Fantasy

Thursday, April 15th, 2010

In an alternative universe:
IBM Toronto
Press Release
April 1, 2010
RPG, from its very inception, has been designed to be an easy to use programming language. Since business data is stored in files, RPG was designed to make reading and writing files easy. To that end, its creators made sure that the processing of files was made easy by its READ and READE and READP operation codes, using a Pascal-like DO loop. Doing subtotals has been accomplished by the programmer storing intermediate data in temporary user-defined fields, then comparing group identifiers with the new identifiers and outputting the results before proceeding. Proper cascading logic enables the user to track multiple group changes that may need to be done at the same time. CHAIN and READ make it possible to easily link related files. (more…)

Education and Programming Style

Saturday, October 3rd, 2009

I have been thinking a bit about how our backgrounds, educational and otherwise, may determine at least to some extent the style we use in our programming and indeed perhaps the language we use.

One of my fellow programmers (about my age) graduated from college with a background in computers. Almost immediately he was able to find a position programming in COBOL, then in ALGOL, which is a block-structured language with a relatively free format. He continued to do well at various positions; ultimately, he came to where I work, with many years of experience in programming, but none in RPG. The style here could be described as a blend of RPGII, RPGIII, and RPG/400; fixed format to the core, loaded with indicators. He learned RPG from the ground up in that environment. Sometime after I came along, he was shown freeform RPG.

I, on the other hand learned RPGII from a book and practical experience. I had no computer background when I started to learn. I was of an inquisitive spirit, though, and I advanced in my use of RPG as the language itself improved. I too ultimately became acquainted with freeform RPG.

Now, who do you think uses freeform RPG whenever he can, especially on new programs? You might have guessed it was my partner- if you did, you’d be right. RPG was actually stifling to him; given the freedom to use free format RPG along with the BIFs that work well with it, he has been liberated. On the other hand, as you may judge from this blog, I just have not seen the light or the point. When I write code for new programs, it is in fixed format RPGIV.

We learned to love the way we learned programming, and so our preference now is to do it the way have always learned it, just better.

Illustrating the point that the way we learn to program is greatly influenced by our programming origins was a discussion I just read on an RPG forum about the significance of certain characters when writing CL (Control Language on the AS/400). Instead of indicating a “not equal” test by the common expression *NE, the code used the combination ^=, where the ^ is really a character I can’t find on my keyboard, but looks like the upper-right-hand corner of a rectangle with the top leg longer than the right. The character, as it turns out, is the “logical not”, a character often used in Boolean algebra.

Now, I don’t know who originated that code. Some experienced programmers, though, just did not know what it meant. Therein may lie a tale.

During the time I learned, many if not most of my fellow programmers were not products of any kind of computer science curriculum. They did not learn BASIC or Fortran first, and usually not COBOL, though this was a bit more common. They learned RPG as their first language. They did not learn “computer science concepts”; many, like me, either never attended college or did so only briefly. They may have started as a computer operator, or maybe at another position in their company. Usually it was a small company; it had the smallest capacity IBM computer available, the System/3, or System/32, or System/34. Something about the programming process intrigued or excited them; they persevered, and they advanced.

As time went on, though, and RPG increased in importance, people with a background in computers and computer science began to program RPG. For a long time, they would prove to be stifled if they expected to program like they originally learned to program in other languages. And where the original programmers may have simply accepted, for example, the RPG cycle, and comprehended it entirely, by the time the System/38 came around, programmers who started learning RPG as RPGIII on the System/38 evidently found it mind-boggling.

I can’t count the number of times I have found a test for LR (last record) in the RPG detail cycle in code (usually written by programmers who came from the 38) using an input or update primary file. Unless explicitly set on with a SETON instruction, the LR indicator will never be on during the detail cycle. A programmer who started with RPG II would automatically know this – it would be a part of his upbringing. A programmer who started with a background in computers later would not necessarily know this. This would cause problems if the programmer intended to base output on this indicator test. Usually it would mean that last record calculations and total output would be missing.

Another difference in outlook comes with file processing. A programmer raised on RPGII (usually in a small shop) doesn’t mind the system reading files (primary and secondary) without him telling it to. But I have noticed in discussion forums that people raised on other programming languages (usually learned in college) seem to get bent out of shape if they don’t explicitly get to do the file reading themselves. They don’t really comprehend that this really is quite an advanced feature, much closer to SQL than Pascal.

It would be interesting to find a survey of programmers that told what level of education they had when they first started programming professionally. I would suspect that as a group, RPG programmers would have a slightly lower level of educational advancement than, say, a C or Java programmer. This would especially be true if they surveyed the most experienced RPG programmers. But then, it is results that matter. RPG programmers do not write compilers – we process information so that humans may comprehend it.

When and How to Upgrade Code

Tuesday, December 30th, 2008

I work on code that, when I came to work for my client, was essentially RPGIII/RPG400 or older. Some of the code had been implemented way back in the 1970’s and was migrated forward as newer machines were installed. And the code showed it. (I have found interesting the large number of 80 and 96 byte files in some of the systems, remnants of old punchcard processing programs.) You haven’t lived until you’ve attempted to update a program that has grown over the years to be a 10000+ line, indicator-laden monster. If you’ve been away from the program awhile and you need to make a non-trivial change, you need to spend part of a day, at least, reviewing the program’s processing.

I am normally conservative about program changes. I generally do not rip apart code and rewrite it, especially if it is not broken. But if a program is to be revised, I do generally at least convert it to RPGIV before making even a minor change. As a phrase used by one of my favorite literary characters (Anne of Green Gables) says, doing this allows “more scope for imagination”.

I was making code changes for a conversion project I was working on when I came across a particular program I had seen before and shook my head at. But for some reason, this time something snapped. I just HAD to change a particular chunk of code, even though the code in fact worked. No errors. But how far to change it? I will explain what I did. In the end, what I do will likely be seen as good by some, too intrusive by others, and  not radical enough by still others.


Control Breaks and Sanity

Sunday, May 18th, 2008

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.