× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



That was Gina Whitney, though I think Barbara and the compiler
developers had to make some enhancements as well. IBM has enhanced the
precompiler significantly, and with no doubt that more work remains, I
just want to take a moment and say thanks again to Gina and the rest of
the precompiler team. We appreciate your efforts.

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Christen, Duane
Sent: Monday, December 20, 2010 8:39 AM
To: RPG programming on the IBM i / System i
Subject: 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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.