AW: SQL using subprocedure variables - v5r4

Hi Buck,

This is an enhancement in release V5R4!

In the former releases SET OPTION-Statements could be positioned on any
place and it was also possible to specify several SET OPTION-Statements. It
was not checked as far as I know only the first set option statement was
considered.
With release V5R4 a SET OPTION-Statement must be unique in the source and
located before all other SQL-Statements in the source. Otherwise the
precompiler will throw an error with error level 30.

Like your collegue we positionned our SET OPTION statements in the *INSR
which is always located at the end of the main procedure.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok) 



-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Buck
Gesendet: Friday, January 19, 2007 16:52
An: rpg400-l@xxxxxxxxxxxx
Betreff: Re: SQL using subprocedure variables - v5r4

And it still does not "bust" the "(not a) myth", IMHO.
You can still upgrade, use the old stuff.

Had an RPG-SQL program written back for V4R?.  The programmer put SET 
OPTIONS in *INZSR physically at the end of the source code.  It compiled 
way back then and has been running fine since.

Yesterday, another programmer tried to re-compile it (to get a listing) 
and the precompiler failed it because the SET didn't physically appear 
before other SQL (like FETCH).  No code change, not even opened in an 
editor, just a re-compile.  The only fix was to physically move SET to 
the top of the C specifications.

It took some explaining as to why a moron like me would ever recommend 
using SQL embedded in RPG when simply re-compiling would break things in 
addition to the precompiler being essentially RPG ignorant.  That 
programmer left with a scowl, and probably bad words to tell others 
about SQL and RPG.
   --buck