× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Joep Beckeringh
>
> Joe,
>
> MOVE is a viable solution, as long as you stick to fixed format
> RPG.  If you
> plan to move on to free format RPG sometime, it is now time to get rid of
> things not supported in free format; such as MOVE.

This whole line of reasoning bothers me, however.  I haven't so much minded
the evolution from RPG III to RPG IV, because most of what I was used to
using is still available in the new version.  But the move to freeform is
more problematic.  For example, why remove the MOVE opcode?  That's just
bizarre.  The MOVE operations, which allow an easy way to convert data from
one format to another, are very, very powerful.  Why get rid of them?  Why
not just leave them in place?  I can't believe it's very difficult for the
compiler writers to continue to support the MOVE opcodes.  That being the
case, what's the reason for removing them?  Why is MOVE inherently so bad
that IBM wants to remove it from the RPG language?

<SOAPBOX>

This kind of decision indicates to me that the developers of the RPG
language no longer understand the concept of supporting application
development.  Unless someone can give me a very good reason for NOT
supporting the MOVE opcodes, then to me removing them is absolutely
unjustifiable.  I can only imagine that the decision was made by some
"compiler experts" who have never worked a single day in an application
development environment.  More than likely, it's a group of computer science
academicians who have never programmed a business algorithm in their lives.
Put them in a situation with a real business problem and a real deadline,
and they'd fold like napkins.  By the time they came up with variable naming
conventions, they'd have missed the deadline and lost the client.

Not all progress is bad, of course.  Even dumping a few things along the
way.  Getting rid of indicators is an evolutionary step that I can
understand.  They're difficult to use and understand.  But a MOVE operation?
I'm sorry, but if you get confused by a MOVE operation, you don't have any
business designing the next generation of RPG.  Adding interoperability
between RPG and Java is a great idea.  Turning RPG into Java is a stupid
idea.

</SOAPBOX>

By the way, if I'm wrong about the people who made the decision to can the
MOVE operation, please let me know.  I'd love to hear some cogent arguments
about how MOVE is a bad operation that will make application development and
maintenance more difficult.  Then I'd like to see why

     eval b = %editc(%dec(a:%len(b):0):'X')

is better than

     MOVE A B

Really.  Convince me.


Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.