× 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.



Everybody is concentrating on the MOVE and MOVEL but what /free BIF(s) or Op
Code(s) could possibly replace MOVEA?

----- Original Message -----
From: "Bartell, Aaron L. (TC)" <ALBartell@taylorcorp.com>
To: <rpg400-l@midrange.com>
Sent: February 27, 2002 9:02 AM
Subject: RE: MOVE opcode in freeform (was Strange behavior w/%editc)


> >Since the intermixing of free and fixed calcs looks so gawd-awful
horrible,
> no one should even consider using free-form calcs unless they are prepared
> to write whole new procedures or modules in free-form style.
>
> I was hoping you would say this because I wanted to ask why you(IBM)
didn't
> just create a new specification code like Z or something instead of having
> to start and end your code with compiler directives(/FREE and /END-FREE)?
>
> I also agree that you shouldn't code both free and column-like coding in
the
> same program.
>
> Aaron Bartell
>
>
> -----Original Message-----
> From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
> Sent: Wednesday, February 27, 2002 8:51 AM
> To: rpg400-l@midrange.com
> Subject: Re: MOVE opcode in freeform (was Strange behavior w/%editc)
>
>
> Darn, another digest just rolled in while I was writing
> this, and so some of my points are again redundant!  I
> promise, this will be my last post for the morning!
>
> Bob wrote:
> >I think the bigger question is not even if a language that supports both
> >free format AND fixed format useful, but rather, is the programmer that
> >uses both free format and fixed format doing the right thing. In that, I
> >can see your point. Mixing a MOVEL with all that free-format code isn't
> >"cool".
> >
> >But to be honest, I have yet to see one example of free-format RPG IV
> >code posted to this list that has been written in a way that is similar
> >to code written by people that write applications with free-format
> >languages for a living (not as a hobby). So perhaps we should continue
> >using traditional RPG IV syntax (which includes the good old MOVE
> >opcode) until we get a bit more experience or until is become more
> >refined.
>
> You know Bob, I DO tend to agree with you more often than
> you might think.  I understand fully your concerns about
> free-form calcs, and to a large extent, much of the talk
> about free-form calcs is indeed hype.  (Perhaps even from
> us!)  Since the intermixing of free and fixed calcs looks
> so gawd-awful horrible, no one should even consider using
> free-form calcs unless they are prepared to write whole new
> procedures or modules in free-form style.  Although I do
> prefer coding in /free style, and I would like to see more
> /free code out there, I'm not sure I agree with the large-
> scale conversion of existing fixed-form calcs.
>
> Maybe you were right that RPG programmers weren't ready
> for free-form.  But then, when would they be?  Perhaps
> the problem was that expectations were too high?  I don't
> think any one of us expected the overnight conversion of
> all existing calc code.  Maybe some small percentage of
> new V5R1 code will be written using /free.  Maybe that
> percentage will rise as time goes on.  Unlike every
> other enhancement we've done, this one has relatively
> little practical importance in its first release.  It will
> likely become more important over time as programmers warm
> up to it and learn how to use it.
>
> If anything, I think /free is a really profound statement
> from us that we believe programmers will still be using
> RPG many years from now.  In a sense, /free is more useful
> as a statement of IBM's commitment to the language, rather
> than as a useful function.
>
> >On the other hand, since we have 6 or more ways to do the ADD operation
> >in RPG, why not just include a new free-format opcode named MOVE and
> >MOVEL?
> >
> >/free
> >   movel  src  target
> >/end-free
> >
> >Oh crap! I just wrote free-format, and I told Hans I would never do
> >that! ;)
>
> That's not valid free-form calc code anyways, so it doesn't
> count, OK?  ;-)
>
> As I pointed out in my previous note, we purposely did not
> support all calcs in /free for the very reason that we
> should not have lots of ways to code something.  If, and
> this is a big IF, all new RPG code is written using /free,
> then the point is moot - there would be fewer alternatives
> to choose from.
>
> >Actually, Joe, Hans is not your enemy. The enemy is us as a group, we
> >RPG programmers who do not clearly articulate our views.  I think rather
> >than say "I demand feature X in RPG" we need to say something like:
> >"Feature X is valuable to me because A, B, C, D... and this is how I
> >think it should be implemented."  And then let the smart compiler
> >writing figure out how it should be realistically implemented.
>
> I agree.  Often we see requests that we should add some
> particular functionality where the request is worded in
> terms of some specific syntax.  What we try to do is extract
> the real requirement and then try to determine the best way
> to meet that requirement.  That's not always easy, and it
> might not always be obvious how some enhancement meets a
> particular requirement.
>
> Basically, we prefer adding "enabling" enhancements, rather
> than enhancements that directly meet some specific need.  For
> example, procedures "enable" a lot of functionality.  For
> many things that programmers want to do, we would prefer
> that programmers write procedures to perform the desired
> tasks.  We had hoped that there would by now be a goodly
> selection of procedures and modules commonly available
> written by RPG programmers for the benefit of other RPG
> programmers.  Robust publically available function libraries
> is a prominent feature of many other currently popular
> programming languages, such as C++, Python, Perl, and Java,
> and is a big reason for the success of those languages.
>
> I know someone will pipe up and point out some web page or
> another with publically available RPG code.  But often,
> they're just touted as "demonstration" code.  The biggest
> problem is that there's no common repository of the code
> that's available.  And there's little sense of community
> with respect to improving the quality of publically
> available code (as there is with other languages).  At any
> rate, the amount and quality of publically available RPG
> code just doesn't compare to what's out there for other
> languages.  Just look at www.cpan.org to see how the Perl
> community deals with library packages.
>
> Cheers!  Hans
>
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.