RE: SQL Precompiler Issues on V5R3

Steve;

The 6.1 pre-compiler is leaps and bounds better than the V5R3 pre-compiler. There are still some quirks in 6.1, but in your case and the quirks in the 6.1 pre-compiler is that they do not fully "understand" variable scoping. I don't know how much effort Barbara(???) and co. are putting into the pre-compiler of the future but at some point there are diminishing returns. The pre-compiler would have to be nearly as "smart" as the RPG compiler, not to mention Cobol and C compilers.

I believe that Barbara, or someone on a midrange.com list, has mentioned that the current design of the pre-compiler/compiler does not lend itself well to handling these situations properly. I would suspect that this won't change in the near future.

Duane Christen


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Steven Harrison
Sent: Monday, December 20, 2010 12:39 AM
To: RPG programming on the IBM i / System i
Subject: RE: SQL Precompiler Issues on V5R3

Just as a quick follow up to anyone who might be interested. In my
module, above the procedures GetPurchaseOrder and
GetPurchaseOrderByNumber, was another procedure which also had a
parameter named 'order' of type purOrderTemplate as well. This procedure
doesn't contain any SQL though. Moving this procedure below the
GetPurchaseOrder and GetPurchaseOrderByNumber procedures in the module
made everything compile correctly?!?

My only guess is that if you are using the same local variable names in
your procedures, make sure the procedures that include SQL come before
any that don't.

To be honest I can't believe the SQL pre-compiler is as flaky as it is.
I know we are on V5R3 but it's a bit of a shame when you have to abandon
best programming practises to accommodate the compiler...

Cheers,

Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Steven Harrison
Sent: Monday, 20 December 2010 11:34 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: SQL Precompiler Issues on V5R3

Hi All,



I'm currently stumped as to what the SQL precompiler is doing and was
wondering if anyone could shed any light on it.



I have a copy file that contains DS descriptions like below:



D purOrderTemplate...

D E DS ExtName(PURORDERS)

D Qualified

D Based(dummyPointer)

D isNew Like(Boolean)

D isDirty Like(Boolean)

D isDeleted Like(Boolean)

D isValid Like(Boolean)





I have two subprocedures called GetPurchaseOrders and
GetPurchaseOrdersByNumber.



They have a procedure interface as follows:



D GetPurchaseOrder...

D PI Like(Boolean)

D orderId
Like(purOrderTemplate.OrderId) Const

D order LikeDS(purOrderTemplate)

D lines LikeDS(purLineTemplate)

D
Dim(PURCHASE_ORDER_LINE_ARRAY_SIZE)

D numLines Like(Integer)

D sundries LikeDS(purSundryTemplate)

D
Dim(PURCHASE_ORDER_SUNDRY_ARRAY_SIZE)

D numSundries Like(Integer)





D GetPurchaseOrderByNumber...

D PI Like(Boolean)

D number Like(purOrderTemplate.Number)
Const

D order LikeDS(purOrderTemplate)

D lines LikeDS(purLineTemplate)

D
Dim(PURCHASE_ORDER_LINE_ARRAY_SIZE)

D numLines Like(Integer)

D sundries LikeDS(purSundryTemplate)

D
Dim(PURCHASE_ORDER_SUNDRY_ARRAY_SIZE)

D numSundries Like(Integer)





If the following two procedures have the following code in them
everything compiles fine:



Exec SQL

SELECT * INTO :order FROM PurchaseOrders WHERE OrderId =
:orderId;



And



Exec SQL

SELECT * INTO :order FROM PurchaseOrders WHERE Number =
:number;



I don't want to use the '*' though so I replaced it by specifying all
the individual fields in the table in the SELECT statement and placing
them in each individual field in the DS.



Exec SQL

SELECT OrderId, Number, SupplierId, WarehouseId...

INTO :order.OrderId, :order.Number, :order.SupplierId,

:order.WhseId...

FROM PurchaseOrders

WHERE OrderId = :orderId;



Now the compile fails with an SQL0312 - Position 32 Variable ORDER not
defined or not usable... with the same error for all the fields in the
DS. Strangely, if I leave the second SQL select that compiled correctly
as is (copying directly into the data structure with '*') it still fails
even though I haven't made any changes to the second procedure? To
finally make things even more confusing if I declare a local DS in the
procedure such as:



D temp DS LikeDS(purOrderTemplate)



And then use this in the SQL instead of the parameter everything works
fine again??? This is driving me crazy as there seems to be no
consistency in the precompiler. I have used this style of coding in
other modules in exactly the same way with out a problem... Note: I also
compile the SQLRPGLE with RPGPPOPT set to *LVL1.



Cheers,



Steve