Re: Preventing a divide by zero error

I would check for a zero divisor prior to doing the arithmetic. I try to
stay away from the monitor statement as this will leave a message in the
job log that there was an error even though it was trapped. This trapped
error confuses the other programmers I work with when they trouble shoot
jobs. i have been told multiple times that my programs had an error
because I chose to monitor for it instead on preventing it.



I think monitor is a great tool, but it apparently confuses others that
read through job logs.



I think it is more efficient to monitor for an infrequent error rather
than executing multiple lines of validity code every time when looping.



Rich

------ Original Message ------

From : Michael Ryan<michaelrtr@xxxxxxxxx>
To : RPG programming on the IBM i (AS/400 and iSeries);
Sent : 6/21/2013 07:14
Subject : Re: Preventing a divide by zero error


No, that's what you would do. You could also place a Monitor group around
the statement. You would then execute the statement and 'catch' the error.
I would check the divisor for zero myself.


On Thu, Jun 20, 2013 at 11:24 PM, Clay Carley <cbc@xxxxxxxxx> wrote:

> This sounds like an easy an easy thing to check for, but here's what is
> going on:
>
> I'm studying (on my own) RPG IV using Stanley Myers' book, "RPG IV
> Programming on the AS/400". I'm doing the programming assignments at
> the end of Chapter 5, and assignment 5-2 wants "Include the control that
> prevents a divide-by-zero error". As far as I can tell, this hasn't
> been discussed in the book yet; so I don't want to jump ahead with a
> solution that isn't what they are really looking for.
>
> This is what the line in question could be something like:
>
> C EVAL GRPFT = NETPRICE / GROSSPRFT
>
> Is there some EVAL option I'm missing for this? Setting indicators is
> discussed, but for the life of me I don't see anything related to divide
> by zero.
>
> I did some searching, but I found what I would logically do to check for
> a zero in the variable before doing the math. That hasn't been covered
> in this book yet, so I'm guessing there is something else to it.
>
> Thanks,
> Clay Carley
> Sonic.net/ Sonic Telecom
> --
> This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.