Re: Free Form RPG Opinions Wanted

Joe,

>... one of the leading causes of software failure in our industry -
>the fact that software that worked yesterday doesn't work today because of
>some change to the operating system that breaks working code.

This has nothing to do with the arguments about MOVE or %fields() or %kds().
Absolutely ZERO working code breaks.  Neither do the techniques you or any staff
have learned over the years suddenly quit working.

IBM is adamant about upward compatibility of code almost to a fault -- my
favorite case in point being how the READ opcode formerly failed to reset the
EOF indicator prior to Full-Procedural files.  So a "Demand" file READ had to
perform a SETOF prior to the READ, or any indicator in the EOF column could
carry over the status from a prior calculation.  I've seen lots of program bugs
(in years gone by...) caused by programmers failing to SETOF the indicator
before the READ, and never seen a program which intentionally relied on that
nuance to operate correctly.

Yet IBM would never change that behavior due to existing code, even though if
the program did operate differently it was highly likely to be operating right
for the first time in the life of the program.  Even today a Demand file in RPG
II will fail to set off the EOF indicator prior to the Read; that only occurs
with full-procedural files.  But you can no longer code a Demand file beyond RPG
II, and deprecating that usage was the best way of forcing people away from
repeating the same error prone code.

When converting RPG III to RPG IV, many people have a tendency to want to use
the more natural mathematical expression support of EVAL than separate ADD etc
opcodes and temporary variables.  And in so doing are on occassion receiving
run-time errors for result field overflow.

More often than not, with the dastardlly exception of date manipulation, result
field truncation of significant digits is NOT intentional.  Neither was it
always immediately apparent it had occured.  Programmers have a tendency to
ignore warnings like "Result field may not be large enough".

MOVE is a little like the arthmetic opcode truncation problem, except that in
the case of MOVE it was appropriate coding even when you intentionally wanted
truncation or subsetting of fields, or in some cases conversion between
character and numeric field types.  Yet none of those intentional uses were
obvious by looking at the code itself.

You may argue, "So what?  Programming is not supposed to be easy."

Over 20 years ago when I started programming in RPG, I might have agreed with
that and thought the terseness of RPG was a real strength.  I liked how a single
opcode, MOVE, could do so many diverse things and how quick it was to bang out
new code with few keystrokes.

Over the decades, I've come to realize the relative importance of maintenance in
the life cycle of a program, and how overloaded opcodes like MOVE impede the
immediate understanding of the original intent.  It is one thing to be be
intimately familiar with all field names and attributes as you create the code
and are well aware of how the MOVEs will behave (assuming you understand all the
nuances of it).

It is quite another to examine code you've never seen before, or not in years,
and have the same confidence level in exactly what each statement is doing
without resorting to a compile listing or other means of determining the
attributes of the operands.  What does:

     C                   MOVE      A             B

do?

Although it may look "readable", the truth is you can't tell what it does, just
from the code given.

Since switching to RPG IV, I completely got away from coding a new MOVE or its
variants like MOVEL.  Years ago.  I *always* use EVAL, even with fixed format
specs, and even if it takes more keystrokes to add %subst() or %editc() or a
call to convert between alpha and numeric or whatever.  I don't miss MOVE in new
coding any more than I miss a DEMAND file type.

It really doesn't take much longer while entering new code, and it makes future
maintenance so much easier (IMHO), because the intent and exact function is
obvious.  

Do I have hundreds of thousands of legacy lines of code littered with MOVE
operations?  Sure, with lots of the programs converted to RPG IV.  I'm of the
camp where no maintenance should be done in anything but RPG IV.  If the program
needs to be touched, you convert to RPG IV as the first step.  Do I convert all
existing MOVE operations?  No, because I currently don't have a tool that does
it for me.

Do I consider that IBM's job?  No; I want them adding features that I, or a
third party like Linoma or magazine utility, can't.

Does the lack of MOVE support in /free become a make-or-break decision in
whether a shop allows /free?  Not in any shop I am familiar with, although I'll
defer to Jon's greater exposure where he isn't either.

Does the lack of support in /fixed for certain new features, like %fields(),
bother me?  No; columnar constraints create constraints.  If they can advance
the language under /free with features which were not practical under /fixed, so
be it.  I'm not going to insist they find a way to shoehorn it into /fixed.

If we back up a dozen years to the debates during V2Rx of what RPG IV should
look like, one of the arguments for /free was it would make the compiler
writers' job easier and enable the addition of features not practical with
/fixed.

How hard would it be for Hans & Co to allow a relaxed syntax variant of CHAIN or
UPDATE or whatever in /fixed code?  I'm not in a position to answer that.  From
the outside, one might guess it would be practical.  Whether that presumption is
accurate is another matter entirely, and one I'm not qualified to answer.

Doug