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.

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!
–
Duke

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.

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.