|
Joep Beckeringh wrote:
... Sometimes overflow can be harmful, but is easily repaired afterwards: I once used too small intermediate fields in a currency calculation, loosing 6 million Dutch Guilders (appr. 3 million dollars) in the process. Luckily it was RPG III, so the process completed normally. The next morning the customer immediately spotted the deficit; they repaired the database with a few corrective bookings and I repaired the program. Had the program stopped at the overflow, I would have had to clean up a half completed invoice process. Believe me, that would have been a mess. So, overflow can be dangerous and stopping with an error is a sensible default action to take. But I think it was unfair that, until MONITOR was introduced, it was the only possible action and that there was no way for a programmer to deal with it other than delving into condition handlers. Just EVAL(E) would have done the job nicely.
But since there _is_ now a more granular way to handle exceptions, it seems to me that going to RPG IV is a good opportunity to discover and clean up the kind of overflow errors you describe. Getting the exceptions after the new version has gone into production would be annoying, but doing a conversion to RPG IV is just like any other change to an application. You test the change, and put it into production. And no matter how hard you try and how wonderful your testing is, sometimes it happens that there are problems.
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.