Re: Preventing a divide by zero error

On 20 Jun 2013 20:24, Clay Carley wrote:

<<SNIP>> 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. <<SNIP>>

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.

The "control that prevents" might have been covered already within or prior to the alluded topic of "Setting indicators"; having reached whatever is the current point [Ch. 5] within the book. Have _conditioned calculations_ been covered?

Conditioned calculations are available when using the fixed-form C-spec Calculation Specifications as shown with "the line in question" shown; i.e. non-free-form coding. Using a [non-control-level] Conditioning Indicator, Positions 9-11, to effect the "Indicators Conditioning Calculations" is described in the following page and then two pages later, of the RPG Reference; possibly something also since covered in the book being used:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasd/sc092508123.htm#wq165

Thus, an indicator can condition that line of code. Having initialized the value of GRPFT to something reflecting an appropriate overall effect in later calculations [e.g. perhaps initialized to zero], along with previously having set an indicator to reflect the condition of GROSSPRFT=0, that since-conditioned line of code would not be executed. Having conditioned the line of code, the divide-by-zero could be prevented by avoidance; i.e. avoiding performing the evaluation of the expression, implicitly preventing an error MCH1211 and the RNQ0102.

If the /general indicator/ 10 [i.e. *IN10] reflects the dividend for the expression is a zero-value, then the given line of code, as modified below [as the second C-spec line], will not execute:

C EVAL *IN10 = ( grossprft = 0 )
C N10 EVAL GRPFT = NETPRICE / GROSSPRFT

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.

I was unsure if the above quoted text implies that the above EVAL to set the *IN10 was what was found by effectively /looking forward/ in the book, and thus implying something that was not yet covered... or if perhaps implying that something else that was found "to check for a zero". Considering the prominence of indicators however, I expect how such an indicator could be set, would already have been covered by the fifth chapter.

But for lack of mention of /conditioned calculations/ and their conspicuous value in avoiding the error by avoiding the attempt to evaluate the expression, plus a followup message seeming to imply that what had been found [but was "not yet covered" in the book] was "IF statements", I figured I would spell-it-out in my above reply. The conditioned statement is just some obscure fixed-format conditional logic as contrasted with the more conspicuous logical test of a condition when predicated with the more visible OpCodes like IF.