Archive for December, 2008

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.


Learning Oberon-2

Tuesday, December 23rd, 2008

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.

Fetch Overflow

Thursday, December 18th, 2008

Fetch Overflow is one of those somewhat obscure programming constructs that a “modern” programming language lover would likely scorn or ignore, but it epitomizes what makes a programming language like RPG special.

Fetch Overflow requires Output specifications, which are being used less and less, and it requires the use of an overflow INDICATOR (aaaaaggghhh! See the Java programmer running away into the bushes.) Some RPG programmers may not even know how to use it; more’s the pity.

For those applications that continue to generate reports on real paper, the problem of handling end-of-page conditions, including when to print headings, has always been an issue. RPG’s use of the overflow indicator (which may be OA-OG or OV - OVerflow, get it?) has always been to me a very elegant way to generate proper report appearance.    You can condition lines of print on the indicator, if you use O specs. The system default for printing is a 66 line page, with overflow at line 60; but this can be adjusted to suit the needs of the application. Even with an externally defined print file, you can define a numeric overflow indicator and print lines and do jumps to new pages at page overflow.

There is a column (I believe it is 15 on the standard RPG specification,something different on the RPG IV O spec), where you tell whether it is (D)etail, (H)eading, (T)otal, or (E)xception time output. The next space to the right is where you can put an F, for Fetch Overflow. When this occurs, the programmer is assuming that there will also be some other lines conditioned on the overflow indicator, usually specifications that tell the program to advance to the top of the next page and print defined headings, often several lines of them. If the printing on the page has reached up to or past the overflow line (let’s say line 60), and that line meets the requirements for being printed, the program will print all the lines conditioned on the overflow indicator (let’s say OF), then print the line that fetched the headings, then set off OF.

In the past, often the OF indicator would be used in conjunction with the 1P (first page) indicator. But there is available an even slicker way of handling the headings. Use an *INZSR subroutine, which is automatically executed before any files are read. In that subroutine, insert   SETON   OF   or    EVAL *INOF=*ON.

Now, what happens when the first detail line is read with the Fetch Overflow flag? It notices that OF is on, so it proceeds to print the heading lines you have conveniently conditioned on OF. OF is then turned off. The next time a real page overflow occurs when that Fetch Overflow Detail (or Except, or Total) line shows up, the headings are printed again.

What is beautiful about this process is that it is almost invisible. There are no calculations telling the program to print headings. Except for that *INZSR line of code, there are no lines of code that set on the OF indicator. The indicator is (except at the start) controlled entirely by the system. No calculating of total lines printed on the page. If  there is some chance of there not being any detail lines to print, yet you still want headings, you can generate at the end an Except line with Fetch overflow that says “No records read” - or even a blank line. In either case, it will detect the OF you set on and print the headings before printing the line of desired detail output.

I have not noticed any feature like this in any other general-purpose programming language - but then RPG is NOT a general-purpose programming  language. As I have said in earlier posts, it is designed to push data around, update files and print reports. Input, process, output.

Quite frankly, I think Fetch Overflow  is the kind of feature that writers of RPG should be proud of. Very slick. More recent applications of the language have tended to shy away from emphasis on the report generation facility of RPG, but that should not detract from our recognition of the terse elegance and power of RPG.