RE: The target for a numeric operation is too small to hold the resul t (C G D F)

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx / Ted J Barry
> Sent: Saturday, July 24, 2004 6:55 PM

>  What Rob said I guess?!  I just don't want to have to go to each
> db that has the field that is smaller in size and have to make it
> bigger.  Did Z-ADD just drop all digits to the left of decimal
> that wouldn't fit?

Not quite.  Using the arithmetic op codes had this neat little feature (?)
of allowing high-order digits to be truncated and never letting you know
about it.  This was cool in those days when we used to switch MMDDYY dates
with YYMMDD dates by multiplying by 10000.01 and 100.0001 (remember?), cuz
we relied on overflow to ignore those truncated high-order digits.  Try
doing that with EVAL.

> I guess I'm looking for some easier solution
> to EVAL.  What would most folks do in this situation, without
> having to change database field sizes?

I think you're asking the wrong question.  What would CEO or CFO say if you
told him/her that the maximum you could ever bill somebody was $99,999.99
because anything higher than that won't cause any runtime error.  I know
what my boss would say.

db