Re: Free form code suggestion

[Hans Boldt <boldt@xxxxxxxxxx>]

John Taylor wrote:

> From: Hans Boldt
>
> > OK, I get your point. Theoretically, the compiler could assume that 
> > any spec with blanks in positions 6-7 is a free-form calc spec. 
> > That's certainly doable, and if I recall correctly, I believe it was 
> > considered during V5R1 development. I believe the idea was rejected 
> > to discourage the mixing of fixed and free-form calcs, which, if 
> > allowed, would wipe out much of the benefit of free-form coding.
>
>
> Ironically, the present methodology works best in those situations where
> you have a fixed source member in which you need to use some new feature
> - such as one of the new BIF's. Embedding one or two /FREE tags isn't
> too bad when viewed within the context of the whole source member.
>
> It's when using the latest, greatest features that things start to get
> really ugly. For example:
>
>  //free
>    set some selection criteria...
>  //end-free
>
> C/exec sql
> C+  open a cursor
> C/end-exec
>
>  //free
>    test for errors and/or warnings
>  //end-free
>
> C/exec sql
> C+  read a record
> C/end-exec
>
> Looking at source that's littered with those tags makes my hair hurt.
>
> If you wish to discourage the mixing of fixed with free-from, then
> please consider giving us something like SOURCETYPE(*FREE|*MIXED). *FREE
> to clean things up, and *MIXED as the default in order to maintain
> backward compatibility.
>
> Providing us with a way of eliminating the tags would be an incentive to
> keep our free-form source exclusively free-form. 
> ... 

No arguments here. We've been pushing Rochester to enhance the SQL 
preprocessor for RPG with a free-form version of the EXEC SQL 
statement. It may well happen eventually since Rochester is indeed 
keen on improving the prep. But this necessary improvement is not in 
the current batch of items under development.

Cheers! Hans