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

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

Barbara,

that is great info!  thanks.

does that view matching also apply to variables?  For instance, if the pre
processor is mimicing namespaces and concating the namespace name to all
variables declared in the namespace.  Would the programmer be able to "eval"
the variable using the simple name?

I'll find out myself in time.  Just asking in general if variable names are
mapped from debug view to view?

-Steve


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Barbara Morris
Sent: Monday, May 12, 2003 2:30 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: debugging pre processor code. was: Using OO concepts in RPG


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.

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.