This is a late response to several posts about debugging MI code, which was posted in the February "column". First of all, how does Gene Gaunt and others (et al.) figure out stuff like "the internal template-creating program below the wrapper that is QPRCRTPG API accepts a one-character parameter that means,'omit symbols that begin with this character from the symbol table'. The QPRCRTPG API passes a period...". I would never have figured that out in a million years! It be kind of cool if one could sort of "fool" the program call by QPrCrtPg, to pass any desired character to "hide" from the symbol table. For example, I would vote for some funny hex value like X'FF' that I would never use as part of a variable name! (or, if IBM is too smart and would ignore X'FF', perhaps the "!" sign. I never would use that in code; I don't really like it in C either, where it means NOT (!= is "not equal" Dumb.). I would think it would be possible to copy QPrCrtPg, and modify it to pass any symbol desired. Although of course I don't do that sort of "hacking" stuff myself! Then call QMyCrtPg, not QPrCrtPg. Maybe the system domain/user domain issue would stop that idea. Or not? I guess QPrCrtPg is user domain; otherwise we could not (easily) call it. More to the point, as one of you mentioned, it is indeed possible to display the .Dot-Variables by using their ODT numbers, as in DSPPGMVAR PGMVAR('/0010'), where ODT number 16 would be a dotted variable. But it would be quite tedious to keep a compile listing on hand and look up the ODT number everytime you wanted to track a .DOT variable. A better solution would be to have a source debugger that could track the .DOT variables in the source (a parsing task) and change any "Dsp .Dotted_Variable" request to an ODT reference under the covers, using DSPPGMVAR with the proper ODT number argument. That would not be hard to do; just tedious, to write the appropriate parsing code in the debugger and create some sort of .Dot_Variable/ODT number table. I have just such a source level debugger that I have written to "play around" with MI program debugging. It is written in ILE RPG, although for the parsing tasks, perhaps calls to C functions (like strtok) would have been easier, in retrospect. It does not, however, have the above-mentioned ODT number table logic in it, because at some point I had to go out and get a real job and, sadly, stop playing around with MI! It does most of the things the IBM OPM debugger does, with the glaring defect that it does not do a true "single step" function. Mark Waterbury gave the me the idea of how to implement that function (by again, parsing branch points and setting temporary break points at all possible branch points in an MI statement; that is, for any statement that has an implicit or explicit branch. I did not, however, implement this yet, either. The "single step" function just sets a temporary breakpoint at the next sequential MI instruction in line, and when (IF!) that breakpoint is reached, removes it. Obviously, if the program branches around the breakpoint, the single step goes on forever (until another breakpoint is reached or the programs ends, or the computer gets tired). This source debugger is sort of a "beta version", but it does work and it is more fun, I think, to use than the simple-but-tedious (VERY tediious) method of setting breakpoints manually and displaying program variables manually, by using the relevant CL commands. That is the way we used to debug RPG programs on the System/38. It was great at the time, but now...! Anyway, I offer this debugger to anyone on the list, gratis; if anyone wants to play around with it. P. S.: I like to use the "^" character for pointers, just for the record, if I want to be able to easily display them. But, perhaps because I got used to Leif's coding syle, I like the .DOT character best for coding pointers. -- rich hart --
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.