Re[2]: X-Spec (was: "RPG isn't cool")

[eric.delong@xxxxxxxxxxxxxxxxx]

     HELLO!!!!! Wake up! There's no requirement that you have to use CF 
     coding specs. If you want to use them, fine. Otherwise forget about 
     it. I do NOT thing it's IBM's responsibility to convert your (or 
     my) old garbage into CF. Someone would write a conversion utility 
     to do this (Bradley <g>) eventually. BTW, have you already 
     converted all of your RPG to RPGIV? Did you use IBM's tools, or 
     third party?
     
     eric.delong@pmsi-services.com


______________________________ Reply Separator _________________________________
Subject: Re: X-Spec (was: "RPG isn't cool") 
Author:  <MIDRANGE-L@midrange.com > at INET_WACO
Date:    5/12/99 3:12 AM


Carsten/David,

>4) No  - I'd rather see the ++ function added and as for overflow
>issues          I'd prefer to code defensively where appropriate - this
>will            also make my intentions clearer for the next
>programmer                 having a look at the code.

While I agree with you on new code, how do you propose IBM should
convert legacy code to CF for us?  You'd need a conversion option like
some of the third party tools to enhance CVTRPGSRC where you could
choose whether or not to convert to EVALs.  But when you didn't,
wouldn't you still rather have the arithmetic opcodes be free-format
so the code can be indented properly?  I sure would.

Another dilemma occurs with the I/O opcodes.  I fully agree that new
code should use the BIFs instead of resulting indicators.  And where a
conversion utility can recognize that it is safe to drop I/O resulting
indicator(s) and change conditioning indicators to a BIF, I'm all for
that too.

But what should a conversion utility do when I/O resulting indicators
cannot be reliably dropped and conditioning indicators changed to a
BIF?  We all have seen plenty of legacy code which would fall into
this camp because references to the indicator were not localized to
the code following the I/O, and the same indicator was used as a
resulting indicator for something else in another part of the program.


Or what if the I/O resulting indicator was used as a conditioning
indicator in an external DSPF or PRTF?  Should the conversion utility
check the DDS to see if it is used?

I'm all for using BIFs with new code, but wouldn't it be nice to have
legacy code nicely formatted too?  To me, it seems "cleaner" to have
the conversion indent it properly and add EOF(50) or whatever than to
switch to fixed format for the line.

What do you think?
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---