Re: converting string to a numeric

> But I do think the MOVE and MOVEA
> statements ought to have come with some
> sort of "pad" or "fill" option.

In RPG III you put a 'P' in column 43 - the half adjust column.  In
RPG IV you use the (p) operation code extender.

The MOVE issue is a contentious one indeed.  I had a lot of fun
learning the <expletive deleted> nuances over many years.  I'm sure I
have more to learn.  I used to think that if the operation code were
named MSCO (MoveSubstringConvertOverlay) that there'd be less hue and
cry over it's omission in /free.

I fully realise that is also contentious, but what the heck.  What I'm
thinking is that many (not all, but many) people who weigh in on this
subject are only considering the simple cases where MOVE converts
same-size fields from character to numeric or vice versa.  I've had to
roll my own in the earliest release, and I bet others did too.

I would have liked to see some implementation of the 'convert' part of
MOVE in the initial /free implementation, but we are getting there
with individual conversion BIFs.  Having a generic 'convert this to
that' was very powerful because it abstracted out having to explicitly
declare what 'this' and 'that' were to the 'convert' (MOVE) opcode.
Most of the 'substring' part of MOVE is handled by BIFs now; same with
'overlay'

The nasty side effects of inadvertently combining a 'convert' with a
'substring' are unpleasant indeed, and many was the time when I made
such a mistake.  In some regards it's nice that the current compiler
yells at me if I try to eval dateField = %char(numericField).  I
probably typo'd one of those things.

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