Re: X-Spec (was: "RPG isn't cool") -- MIDRANGE-L

Carsten,

>The conversion process itself might also introduce bugs if not carried
>out very carefully, as well as the time spent converting and testing
>will have to be justifiable compared to the relative gain 

If the program is already in RPG IV, then there must be ZERO exposure
to converting to CF specs if simply run through the converter.  If you
are moving from RPG III (or II :), then the exposure would be no worse
then when converting to RPG IV C specs.  And I already do that
routinely.  To me, the CF vs C is a non-issue in terms of introducing
bugs.  (You can already opt to convert math to eval and other
potentially "incompatible" source changes using third party tools.)

>(you know, the old saying "if it works don't fix it").

I thought that was, "If it ain't broke, fix it 'till it is!" :)

>Having said that I think it could be an interesting challenge to follow
>up on your idea developing the tool ourselves - if IBM doesn't provide
>us with an adequate utility - what do you think about that?

I can guarantee there will be shareware/freeware tools and probably
magazine submissions regardless of whether or not IBM provides a
minimal conversion.  

>I've also had second thoughts about carrying the move opcode to the
>CF-specs; 

IBM should not attempt to convert the move opcodes in their utility
(if they provide one).  Let somebody else make the effort.  There are
too many variations, and you haven't covered all of them with your
list.  It is a question of whether IBM should leave the MOVEs in fixed
format using a C spec, or allow CF to code the MOVE variants.  I opt
for the latter because at least then the source is still indented
properly.

>%AtoI (Alfa to integer)                           
>%AtoF (Alfa to float)                             
Just add QC2LE as a binding directory, and prototype calls to the
C-functions atoi() and atof() using a /COPY member for the prototypes.
                                                 
>%Array (Move array)                               
It is much more complicated than that; MOVEA isn't just a horse of a
different color, it is a whole herd of horses all of different colors.

>%Date (Convert to/from date)                              
Service programs with date routines already work real good for this.
                                                           
>Operation extender O (Overlay):                           
I'd much prefer to see %subst() used on the left and/or right side of
the equation.  Then the intent is obvious and readable.  (IMHO)

You also haven't covered some of the worst offenders of MOVE in RPG,
at least as far as the intent being non-obvious.  That occurs when
factor2 and the result field are different data types, but the number
of digits in one is different than the number of characters in the
other.

And you haven't covered repeating figurative constants like MOVE
*ALL'1234'  RESULT.  And numerous other variants.  Like using two
numeric fields with unequal number of decimals, etc.

And then you have to consider the cases when the result field is an
array, instead of a field or array element.  And the list goes on...
+---
| 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
+---