Re: converting string to a numeric -- RPG400-L

Buck Calabro wrote:

...
Although I like talking about the kibbles & bits of this stuff as much
as anyone else, I've come to the realisation that there is a growing
issue with the omission of MOVE & friends that hasn't quite been
touched upon yet.  With enhancements being made to /free and not to
fixed-format, there will be increasing pressure to _convert_ large
blocks of existing code, rather than simply write new, small blocks
(functions) in /free.  I doubt there's any tool aside from the
compiler itself which can reasonably figure out what combination of
BIFs to substitute in place of MOVE.  I believe that this situation is
similar to the RPG III - RPG IV conversion.  People finally decided
they'd move if it was easy; i.e. CVTRPGSRC.  When there's enough
noise/functionality in /free over fixed-format, people are going to
want the same ease of migration that they've always had.

I wish I knew what the answer is.  Perhaps ANZRPGSRC - a tool to
analyse and recommend what to do with non-supported fixed-format
operations?  Truly, I hate the idea of block conversion from fixed to
free-format.  Putting a hat on an old pig won't make it the belle of
the ball (in most places, anyway.)  Converting my 1985-vintage RPG II,
converted to RPG III, converted to RPG IV and finally to /free won't
buy me hardly anything that leaving it in RPG II would have done.

The problem is that the RPG II got converted to RPG III and then
modified some.  Then it got converted to RPG IV and modified some.
The changes (new functionality) are intermingled with the original RPG
II code.  People really are going to want to do the same with /free,
and for some reason refuse, absolutely refuse to switch between /free
and /end-free within the same block of code.  Maybe some of those
folks can chip in with reasons why they won't do that.  We might be
able to get a DCR out of it...
  --buck

No doubt there are people who want to convert existing fixed-form code to free-form calcs. But generally I don't encourage that practice. As far as I can remember, I've only recommended the use of free-form calcs for new code development. That is, new modules and procedures. We knew at the beginning that flipping back and forth between fixed and free calcs within a procedure would be even uglier than horse apples. And so the /FREE and /END-FREE delimiters were added to the design to discourage the switching between the two modes.

There are conversion tools. There's one in IBM's IDE. And I believe there's at least one 3rd party conversion tool. But these can only do a half decent job if the original code follows some fairly modern RPG coding conventions to begin with. That is, no conditioning indicators, no resulting indicators, using of EVAL instead of MOVE, no GOTO's, etc. My guess is that those programmers who use more modern coding conventions already are more amenable to free-form calcs.

For me personally, the debate fascinates me. As in the original fixed or free debate before the introduction of RPG IV, opinions are just as polarized as ever. Issues like language design and user interface design are extremely subjective. And so everyone has an opinion, and everyone is right, and everyone else is wrong! There are always lots of alternatives to choose from. And so the people responsible for the language design have to make their best cut at a decision, implement it the best they can, and then move on. Part of the fascination over debates like this is that in the user community, people still continue to argue vociferously over how the design should have been done!

Another thing that fascinates me is that not only do some people prefer using an older RPG programming style, but that a few actually take pride in it!

There were lots of good reasons why free-form was not adopted initially for RPG IV. Having to deal with conditioning indicators, resulting indicators, and multi-part factors would only have complicated any free-form syntax design. What made the /FREE syntax in V5R1 a reasonable proposition was the realization that modern RPG coding style rendered these complications redundant anyways.

Finally, is it wrong that some people prefer using fixed-form syntax over free? No, not at all. Lots of programmers have to deal with code that goes back 30 years or more, and little of that can be easily modernized. Also, as some have pointed out, some shops use tools that depend on the fixed-form syntax, and that's not an unreasonable justification to stick with fixed-form. But likewise, I think there are some silly reasons for insisting on fixed-form for new development. Such as your favorite fixed-form opcode not available in free-form. Or that some compiler directives are needed to switch modes. (The SQL complaint is valid, and hopefully will be addressed in a future release.)

I'll end this rambling with my prediction that this debate will still be raging 10 years from now.

;-)

Cheers! Hans