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

["Mark A. Manske" <mmanske@xxxxxxxxxxxxxxxxxx>]

IMHO
I disagree - do you have employees or even operators that NEVER answer a
message on their own; You are only fooling yourself if you think so - that
should always be a hard error, the programmer should code accordingly, users
are not to be trusted - IF they could take the option to ignore(and they
will), you would find yourself next week or worse yet next month trying to
answer to the CFO why that report does not total up correctly, and worse
than that, depending on how the program is written, many, many records could
be hosed too, not just one or two - the ramifications are too broad; the
perspective must be from a global issue, not one program, not one
programmer, not even one company, but from a logical mathematical view.
This view brought to you by an "olde" S/36 programmer who spent far too many
times cleaning up whole systems because of that darn ignore divide by zero
option; I for one am glad that IBM is forcing the programmers to clean up
their code, I just wish we could get the windoze people to do the same.




Mark A. Manske
[mailto:mmanske@minter-weisman.com]
Sr. Project Lead
Minter-Weisman



-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of John Hall
Sent: Monday, June 26, 2000 10:34 AM
To: RPG400-L@midrange.com
Subject: 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
+---