Bugged by the Debugger- and Larger Issues

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.

5 Responses to “Bugged by the Debugger- and Larger Issues”

  1. Ralf M Petter Says:

    What is the optimization level of this programm. For debugging it is best to compile with optimization level *none. On other optimization levels variable content may be inacurate.

  2. Curtis Barron Says:


    Thanks for your comment. Actually, the optimization level is the default, *NONE, which makes all of this even more puzzling. I’m still grappling with the concept that the debugger even needs to be optimized. It sure couldn’t be for speed.

  3. Buck Says:

    I’m not sure there ever was a single person who knew EVERYTHING about RPG, much less RPG II, RPG III, RPG/400 or ILE RPG. Any suitably complex language/operating system combination has subtleties that are only revealed through experience.

    That’s one reason I keep adding to the Midrange wiki (http://wiki.midrange.com) - it can be pretty hard to find answers to questions like this. The manual might document it, but finding the answer isn’t always simple. In this particular case, your instinct was correct: the H-specification keyword DEBUG is what you are after. I tend to use DEBUG(*YES) which is equivalent to DEBUG(*INPUT: *DUMP) That will show you unreferenced field contents.

  4. Duke Normandin Says:

    Stumbled upon your blog, searching for an Oberon-2 tutorial. I’m 63, and teaching myself another computer language. ;) How’s *your* journey with Oberon-2 coming along?

    I’m in the same boat as you - I *need* a project to sustain my interest in learning a language - learning *anything* actually. The desire to crank out interactive web-pages motivated me to learn Perl4 and then PHP and MySQL. I’m still searching for an Oberon-2 goal.

    Enjoyed your blog!


  5. Barbara Morris Says:

    Hi Curtis, I’m a bit late here, but I just ran across your blog. This behaviour isn’t aimed at optimizing the debugger, it’s aimed at optimizing the RPG program. If a field isn’t used in the program, the compiler thinks there’s no point in loading it from the input buffer.

    The RPG/400 compiler didn’t even generate those fields into the program. But for some reason, the ILE RPG compiler generates the fields (by default), and just doesn’t load them during I specs. (Now you can code OPTION(*NOUNREF) to get the ILE RPG compiler to handle unreferenced fields like the RPG/400 compiler does.) Either way, it’s going to give you a frustrating debugging experience, but I think the RPG/400 way is slightly less mysterious. When the field is not even available in the debugger, you don’t have to spend any time trying to figure out how if there’s some logic error that caused it to be blank.

    By the way, the ILE RPG Programmer’s Guide does attempt to document this situation. There’s a section called “Unexpected Results when Evaluating Variables” http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507305.htm#wq488.

Leave a Reply