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


  • Subject: Re: [Re: RPGILE V4.3 Gotcha]
  • From: "Peter Dow" <pcdow@xxxxxxxxx>
  • Date: Tue, 5 Oct 1999 15:20:57 -0700

Hans wrote:
> >It depends upon what you're trying to accomplish. Imagine if MULT always
> >failed on overflow. How many programs are out there that used MULT
100.0001
> >or MULT 10000.01 to flip a date around? In one sense, any opcode is
"unsafe"
> >if you don't understand what it's doing. I remember waaaay back when
> >learning RPG after knowing COBOL, and expecting MOVE to MOVEL with
Padding!
>
> Ah, another FAQ!  A long time ago, I did a comparison
> comparing the performance of the old MULT 100.0001 trick.
> I found that using MULT was about 100 to 150 times slower
> than doing the date conversion using a couple of moves.
>
> I have yet to find a good example where using the decimal
> truncation behavior of the old opcodes provides any
> advantage.  Since numeric overflow is almost always a
> programming error, to me it makes little sense compiling
> without TRUNCNBR(*NO).

I'm sure that the old MULT 100.0001 trick is much slower, but I see it used
all over the place, and yes, I use it myself. Advantage? Since you have the
temerity to throw the word "any" in front of it, I feel compelled to come up
with some <G>.  Let's see -- being in some ways a lazy programmer, I could
say it's an advantage to only have to type one line of source code as
opposed to the several required to do the same thing with a couple of moves.
And there are issues of program length - source length - where using one
line of code when two would do might be an advantage.

As far as speed, well, having a couple of MULT's in an interactive program
to reformat dates for output is probably not going to be noticeable to
anyone except someone who has a dedicated machine with nothing else running
on it and a very accurate clock. Even in a batch program I doubt that you'd
think the performance increase was worth the effort to go back through every
program that uses MULT and modify it to use MOVE's simply based on
performance.

This isn't really relevant, but I remember a discussion once about whether
MOVE 1 X was slower than Z-ADD 1 X, so some guy wrote a program to test it.
He had a 10,000 iteration loop for each statement, and running it on a S/38,
couldn't see any difference. So he upped it to 1,000,000 and managed to see
zero seconds difference. I think he finally dumped the MI and found that
they both used the same instruction. We all got a good chuckle out of that.

Regards,

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice/fax


> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---


__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


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.