RE: Debugging MI code

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 --