Re: SQL pre-compiler not recognizing /DEFINEd variable

Just to clarify a little what Buck said.

/Include was added to the compiler to deal with a specific situation - to enable the programmer to include copied source while making it invisible to the SQL pre-compiler.

This was necessary because the pre-compiler had got so far behind the RPG compiler that it was barfing on perfectly valid RPG syntax (because it just didn't understand it). The compiler team introduced /INCLUDE as an alternate to /COPY _because_ the pre-compiler would not understand it, but it would recognize it as a compiler directive and would just ignore it.

So if you wanted to include new RPG features that gave the pre-compiler problems you could just /INCLUDE it and the pre-compiler would never see it.

Subsequently the pre-compiler, in addition to being bought up-to-date, was also enabled to "understand" /INCLUDE as an alternate to /COPY - personally I thought this was a mistake but I believe that it only "understands" it if you request it to.

So - simply put - use /COPY to have things seen by both the pre-compiler and compiler. Use /INCLUDE (and don't set the option) to have only the RPG compiler see the code.



On 2014-09-04, at 11:43 AM, Buck Calabro<kc2hiz@xxxxxxxxx> wrote:

On 9/2/2014 6:24 PM, mlazarus wrote:

I just ran into an SQL pre-compiler situation that seems to be a defect.

When compiling this as an RPGLE, it compiles fine. Changing it to
SQLRPGLE causes it to fail:
SQL1106 30 RPG specification out of order.

It looks like it's ignoring the defined variable and copying the code
again. This is for a client that's still on V5R2. Does this work
properly at a current compiler version?

Yes, it works fine on 7.2. The SQL preprocessor on early versions -
especially before 5.4 - were quite primitive. There is one set of
developers working on the RPG compiler and another set working on the
precompiler. There were periods when the RPG team added functionality
to their compiler but the SQL team hadn't got round to it yet. This is
one of those instances.

It seems crazy, but I think of it like this: The SQL precompiler only
needs to know enough RPG to recognise variable names. Essentially it
can ignore most of the source RPG code; stuff like edit codes and the
like. When the precompiler reads source it doesn't understand, it
/assumes/ that the RPG compiler will, so it doesn't flag it as an error,
and lets it go past. Like /DEFINE. It inserts its expanded SQL code
into the RPG source and then sends the lot off to the RPG compiler.

Here's a test program to illustrate:

H OPTION( *SrcStmt: *NoDebugIO )
H dftactgrp(*NO) actgrp(*new)
/COPY X@
d Test2 pr
C EVAL *INLR = *On
P Test2 b
d Test2 pi
P Test2 e
/COPY X@

______________
Include member X@:

/IF NOT DEFINED(TestPgmPRCopied)
/DEFINE TestPgmPRCopied
* Test prototype
D TestPgm PR ExtPgm('TESTPGM')
/ENDIF

SQLRPGLE source:
h/copy qrpglesrc,stdhspec
d/copy buck/qprotosrc,autocopy

// some calculations go here

/copy buck/qprotosrc,autocopy

*inlr = *on;

QPROTOSRC:
d/if not defined(autocopy)
d/define autocopy
d testPgm pr extpgm('TESTPGM')
d/else
callp testPgm();
d/endif

Resulting compiler listing:
1 h*copy qrpglesrc,stdhspec
2 h dftactgrp(*no) actgrp('QILE') option(*srcstmt: *nodebugio:
000200 h alwnull(*usrctl)
000300 h debug
000400 h bnddir('PROCEDURES')
000200 d*copy buck/qprotosrc,autocopy
000100 d/if not defined(autocopy)
000200 d/define autocopy
000300 d testPgm pr extpgm('TESTPGM')
000400 d/else
LINES EXCLUDED: 49
000600 d/endif
000300
000400 // some calculations go here
000500
000600 /copy buck/qprotosrc,autocopy
000100+d/if not defined(autocopy)
LINES EXCLUDED: 2
000400+d/else
000500+ callp testPgm();
000600+d/endif
000700
000800 *inlr = *on;

--buck
--
This is the RPG programming on the IBM i (AS/400 and 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.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com