Hi All, I thought I would send out the solution to this problem. The IF statement took these values to be different although they appear equal. We used string math as was suggested to us and that worked. Our Vendor (Columbia Ultimate) escalated to IBM, and the suggestion was to use $OPTIONS COMP.PRECISION. We inserted this at the start of the subroutine, and the IF statement handled the comparison as one would expect.
CUSTOMCALC: 451: PRINT INTREC:' ':PRNREC:' # ':INTPAY:' ':PRNPAY :: S 24016.35 978.56 # 24016.35 978.56 IBM's response was: <IBM response> This is a case of 'what you see' isn't what you get. UniVerse is applying a PRECISION to the values on display. Hence, UniVerse might display for example 1.0000 but the actual value stored could be 1.0000000001. In the example (in the case), the values are stored internally as 'float' data types. The comparison using equals or non-equals (=/#) is based upon what UniVerse considers a zero. That is determined by the setting for WIDE0 in the uvconfig. For example would .00000001 (+ or -) be considered a zero? While UniVerse includes several features (WIDE0, $options STRING.MATH, VEC.MATH, COMP.PRECISION) the reason the routines fail in the relational test is not due to UniVerse but do to how floating values are stored by the hardware. A failure in a UniVerse basic program can be reproduced within a c-program as well. One simply needs to do the same arithmatic operations in the same order and the comparison test should be the same. You can change WIDE0 which will for the entire system alter how comparisons (=, >, >=, <, <=, #, etc) are handled. Or, alter the logic for a specific program by adding '$OPTIONS' to the program. Can this problem be worked down to a smaller program, ie. retrieve the fields indicated and do the math, rather than having all of the other program logic included? <End IBM response> Regards, Steve ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
