RE: Target for numeric operation too small...hello, Toronto?

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Well:

D PBcontrol     E DS                  ExtName(PBSCONTROL) Prefix(da_)
D                                     DtaAra(PBACONTROL)
...
In *Lock PBcontrol;
da_Sequence = da_Sequence + 1;
Out PBcontrol;
pa_Sequence = da_Sequence;
...

Where Sequence is a 7 digit number that used to, and still should, just roll
over at hival.  (This is just one example of many sequence numbers)


Of course there is (now):

In *Lock PBcontrol;
Monitor;
da_Sequence = da_Sequence + 1;
On-Error;
  da_Sequence = *Zero;
EndMON;
Out PBcontrol;
pa_Sequence = da_Sequence;

Clearer?  Not to me, but at least at 5.1 it's fixable.

Better alternatives?  Like testing 9,999,999 operations that are guaranteed
to be good to get to the one that's guaranteed to be bad?

Now we're going to go to a dtaq full of waiting sequence numbers to
eliminate any waits for the data area and the problem goes away.  However:

Eval(e) da_Sequence = da_Sequence + 1;

would have been better than the Monitor group.

And in keeping with the current run on the list, 52yo (next week) coding
since 1970 (in college with Fortran IV on an 1130 and Cobol on a 360-35),
full time using RPG II and it's variants since 1/1/77 on S/3 15D, S/32,
S/34; S/38 only starting in 1982, and AS/400 only starting in 1988.

Tom Westdorp
AS/400 Senior Programmer/Analyst
IBM Certified Specialist - RPG IV Programmer
IBM Certified Specialist - RPG IV Developer
Voice: (702) 221-6859
Fax:   (702) 221-6881
tom.westdorp@stationcasinos.com <mailto:tom.westdorp@stationcasinos.com>

==> The trouble with hitting the jackpot on a slot machine is that it takes
so long to put the money back.




-----Original Message-----
From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
Sent: Thursday, December 06, 2001 9:54 AM
To: rpg400-l@midrange.com
Subject: Re: Target for numeric operation too small...hello, Toronto?


Reeve wrote:
>Hans, with great respect I say your answer blames the victim.
>
>This is a possibility for many programs converted to RPG IV, and it's not
>necessarily a "logic" error.  You're asking us to EVALuate every line of
>converted code and consider if a numeric overflow could occur.  I haven't
>had many overflows, but I've had enough to know it's a pain.
>
>The manner in which RPG IV presents this error is unfriendly, and IMHO
this
>issue is one of the biggest reasons people aren't moving to RPG IV and ILE
>RPG.  I think this issue needs some consideration in the Lab.

We have considered the issue.  We've considered it a lot in fact.

Masking numeric overflow within expressions would simply have far
worse consequences than any possible benefits.  Numeric overflow
is almost always caused by incorrect logic in your program, and so
allowing overflow without an exception would be a tremendous
disservice to RPG programmers.  (And for those few programs that
count on truncation, there are better alternatives.)

In RPG III, you have complete control over how a computation
proceeds by explicitly coding intermediate variables.  Within RPG
IV expressions, the compiler must make a best guess as to
appropriate precisions for the intermediate values.  As a result,
what happens within a computation isn't as clear.  If you arrange
the steps of the computation incorrectly, you may well get
intermediate values that get too big (or possibly too small).
Understanding how expressions get evaluated is thus much more
important in RPG IV.  Study carefully Chapter 21 of the ILE RPG
IV Reference manual.

(I learned programming 25 years ago starting with a PL/I subset
language called SP/K.  Even in that first programming course, I
learned the importance of carefully coding numeric expressions to
avoid overflow!)

Also, in RPG IV, you're not just dealing with decimal numerics.
What happens when you mask overflow on an integer or unsigned
expression?  You don't just get truncation of high-order digits,
you get truncation of high-order bits!

When dealing with floating point expressions, you might think a
lot of problems go away because of the incredible range of float
values?  No, even with float numbers you can't get away from the
necessity of understanding how the arithmetic works.  With float,
you don't just worry about overflow - you also have to consider
potential numeric underflow.

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.