RE: Free form code suggestion

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. 

And if you were to PTF this back to V5R1/2, you'd be a hero. :)


Regards,

John Taylor