× 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: The target for a numeric operation is too small!!!!!
  • From: John Hall <jhall@xxxxxxxxxxx>
  • Date: Mon, 26 Jun 2000 11:33:48 -0400

I think this misses the point.  Why cannot the system allow an I
response.  Many have suggested that the program needs to be fixed and
suggested that the only reason to have an I is to give the users invalid
data.

Might I point out that if you take a G you can cause far more damage
than an I which should simply set the value to 0.  Suppose this program
is updating files.  At least if you flag the error this gives you the
chance to allow processing to complete normally and then you can fix the
one record with the problem.  If you take a G you may process all of the
records again and get the same error.  Been there - Done that.

The same argument goes for divide by zero.

On the s36 a divide by zero generated error but you could Ignore it and
allow the process to continue.  The results may or may not have been
correct but the updating of the files could complete in an orderly
manner.  This would permit the programmer to correct the program without
having to restore all of the files which were corrupted by an abnormal
halt to the process.

All he is asking for is the ability to minimize the damage!  The program
should HALT but you should be able to continue processing once you have
identified the problem.  

John Hall


Scott Mildenberger wrote:
> 
> For one thing, the truncate numeric does not apply to values in
> expressions(which is what an eval is), overflow within expressions always
> generate an error(this is from the help on the parameter).  Secondly, why do
> you want your report to have an invalid value versus getting an error?  Your
> report field should be large enough to hold any value expected.  If you want
> your report field smaller then you should check the value in your program
> and print some indication on the report that the value overflowed (like
> ********* or something).  I have seen too many problems caused by reports
> having incorrect numbers due to overflow and truncation.  You should be glad
> the program halted and did not complete with incorrect data as if nothing
> was wrong.  I recommend changing the program to handle the overflow.
> 
> Scott Mildenberger
>
+---
| 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 ...

Follow-Ups:
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.