RPG and Programming

Sometimes the frustration you get from programming stems from a lack of knowledge. You think you have a mastery of a particular programming task, but the lack of knowledge comes back to bite you.

Such was the case a few weeks ago. I was debugging a program, and I wanted to to check the results of a basic calculation. I had changed the processing to no longer use a particular field. This field was defined in the input specifications (it was not externally defined). As I stepped through the calculations, I wanted to check the field, so on the command line I entered EVAL FIELD1. The result? It was blank.

I said to myself, “This is ridiculous- it can’t be!” It was part of the key to the file, and the file had no blank keys. I checked the value of KEY1, which included FIELD1 (that is, it included the data in the record encompassed by FIELD1. It looked normal. This was exasperating. I know that data in input specifications are stored in different areas of memory, even if they describe the same spot in the data record. But the field was blank. There were other fields that encompassed the same record space; some were blank, some weren’t.

I was vaguely aware that there was some sort of keyword in the H specifications you could use to eliminate unreferenced fields. But that would mean that I shouldn’t be able to debug it at all; it should give an error if I tried to EVAL it. And I didn’t use that keyword. I had one of my fellow programmers look over my shoulder as I ran the program in debug again. He didn’t have any idea what was going on either.

After all of this, we brainstormed a bit. I had no reason to suspect it before, but we thought: what if it is not showing up in debug because it is not being used? We could find nothing in the IBM RPG language documentation that something like that is done; but I inserted a dummy calculation: EVAL FIELD1=FIELD1.

Voila! The field now showed up, filled with data, in debug.

The most disagreeable part of it all was that I couldn’t find this behavior described anywhere in the documentation. I spent a little time Googling the situation – and sure enough, others described this behavior of the debugger. Apparently it is some kind of attempt to optimize the debugger. If you don’t use the field, the value is not filled in the debugger.

My reaction was, “Why bother?” Why assume that, just because another line of code doesn’t reference it, that I’m not interested in it? (This is an old program, by the way.) If the field is part of the file’s definition, it should be assumed that I’m interested in its value. I haven’t been able to find the documentation in a text document that describes how to use the debugger. The documentation may say something about it – if there is documentation. I couldn’t find anything in the help text for the debugger that described my situation. And I would think that a debugger, which deliberately allows you to sit at a line of code as long as you want, would be the last and least thing you would need to have optimized.

But all of this speaks to a larger issue. Is this system getting too big? Is there any person around that actually knows everything about the behavior of the RPGIV compiler and its supporting programs, like the debugger? I don’t mean someone who knows where to look for the information (assuming of course that it’s even all written down), but someone who actually knows all this stuff, right down into all of the nooks and crannies, like this thing with the debugger, where some programmer or low-level committee apparently arbitrarily decided that we didn’t need to see the value of an unreferenced field in the debugger? If such a person exists, hide him from the world for six months and make him update the manuals so they include everything IN A COMPREHENSIBLE AND COMPREHENSIVE FORMAT.

I don’t pretend to know the answers to these questions. I don’t pretend to know the solutions to these problems. Maybe I’m just stupid. Maybe I just don’t know where to look. But I have for some time labored under the delusion that I have some measurable level of intelligence and that it shouldn’t be this hard to figure these things out.

This is a rant without a suggested solution. I can’t write my own compiler or supporting documentation. But it just strikes me that when Niklaus Wirth and a colleague can write a non-trivial graphical operating system (Oberon) in just over 12000 lines of code in under 200K of space, other people just as smart could make these systems we work with (possibly) smaller and (certainly) more comprehensible. Maybe it’s too late. I hope not.