|
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
As an Amazon Associate we earn from qualifying purchases.
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.