Re: debugging pre processor code. was: Using OO concepts in RPG

[Barbara Morris <bmorris@xxxxxxxxxx>]

Steve Richter wrote:
> ...
>   d order1       ds            likeds( Order )
> 
>  /free
>       order1.Print( ) ;
>  /end-free
> 
> The pre processor translates the member proc call to std rpg:
>    Order_Print( %addr(order1) ) ;
> 
> For this to work, the pre processor code must be integrated into the ILE
> debugger.  Both versions of the code should be available, but for sure the
> pre processor code, the code the programmer wrote, should be the default
> view.
> 
> Is this possible?
> 

Yes.  You can see it in action with an SQLRPGLE program.  The SQL
preprocessor takes the SQLRPGLE source and generates an RPGLE source
member that it passes on to the RPG compiler - it generates an input
view for the source file and an output view for the output file.  The
RPG compiler doesn't know it's handling an SQL compile - it just
produces the normal debug view on the input file.  The debugger matches
up the SQL output view and the RPG input view so it can associate the
final statement numbers in the RPGLE source member with the original
SQLRPGLE source member, allowing you to step through your SQLRPGLE
source in the debugger.

There's no limit (as far as I know) to the number of times this
input/output transformation can be done.  So your preprocessor would
just need to produce an input view for the source and an output view for
the output.

The debugger APIs (QteStartViewCreation etc) are complex, but the
documentation is pretty good.