Re: The target for a numeric operation is too small!!!!!

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