× 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: "Eric N. Wilson" <doulos1@xxxxxxxx>
  • Date: Tue, 5 Oct 1999 13:49:13 -0700

<Flame on>

I can personally guarantee that the answer will be "It is clearly documented
in our manual see chapter 21...". IBM just as blender manufacturers can not
be responsible for irresponsible use of their product. You know the line "do
not place hand in blender while blender is operating". The same applies
here. A company can only be held responsible if they have not provided
sufficient notification, and by the terms of your licence agreement they are
not liable in any way shape or form for defects real or perceived.

You should be using floating point fields for all of your intermediate calcs
anyway (IMHO) and then cast them to fixed point after you are done. Any BCD
or Fixed point arithmetic routine will run into exactly the same problem in
any language (or at least the 28 I know). It is nice that IBM allows you to
specify the precision of the intermediate values, which is more that I can
say for a great number of fixed point routines I have used in the past.

<Flame off>

By using Mult and Div you are explicitly stating the size of your
intermediate values, I really do not see the difference between that and the
proposed answer by Hans et. al.

----- Original Message -----
From: Jim Langston <jlangston@conexfreight.com>
To: <RPG400-L@midrange.com>
Sent: Tuesday, October 05, 1999 11:38 AM
Subject: Re: [Re: RPGILE V4.3 Gotcha]


> Well, my whole point is, Hans, that this is something that will effect all
> of us sooner or later, and the only way we knew about it was by someone's
> program failing.
>
> It is not expected behavior as I am used to math functions acting.  And I
do
> not always look at all error message when I compile.  But I try to make it
a
> habit to look at the messages and what they are telling me.
>
> I can do all this, but I will never again trust Eval to do what I expect
it to,
> which is not a good thing.  Which means I'll probably use MULT and DIV.
>
> But what about the programmers that don't read this mailing list?  How are
> they going to know, until some number cruncher finds that things aren't
adding
> up like they are supposed to, looks at the data and sees inaccuracies all
over
> from decimals, and tell the programmer.
>
> Then the programmer will, hopefully, find out what is going on.  Then
he/she
> is going to have to explain to management why all their data is corrupt.
This
> is not that far fetched, do you agree?
>
> And will the answer IBM give them be, "you should of read the manual"?
>
> Regards,
>
> Jim Langston
>
> boldt@ca.ibm.com wrote:
>
> > Colin wrote:
> > >I have to say that I agree with Hans.
> > >
> > >What do you mean you shouldn't have to read the manual. They are there
> > >to be used, there's nothing embarrassing about refering to the manual,
> > >and I can't understand why some people think there is.
> > >If I hadn't picked up the CL manual all those years ago, I'd probably
> > >still be an operator today.
> > >
> > >How do you learn new tachniques, without reading up on areas that you
> > >are not currently using.?
> >
> > Well, to be fair, there are some tips that aren't mentioned
> > in the manual that perhaps should be.  Such as checking for
> > message 7551 in the compile listing to see if any expression
> > is dropping any decimal precision.
> >
> > Also, if you don't want to look at the compile listing after
> > every compile, you could always "CHGMSGD MSGID(RNS7551)
> > MSGF(QRPGLEMSG) SEV(30)" and your compiles would always fail
> > whenever you code an expression where decimal precision is
> > lost.
> >
> > Cheers!  Hans
> >
> > Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.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
> > +---
>
> +---
> | 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
> +---

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