Yes, that is one of the issues with the 10.n release of UniVerse.  Note, all
of my customers use the PICK flavor of UniData and UniVerse.  I always use
OCONV and ICONV statement to control rounding and number of decimal places.
Here's an example:
        ITEM.DISCOUNT=OCONV(ITEM<41>,"MD2")
        UNIT.PRICE=OCONV(ITEM<20>,"MD2")*(1-(ITEM.DISCOUNT/100))

Note, we 'almost' never store formatted data (i.e. decimal places, dates,
times) and if I was to save the above UNIT.PRICE I would do so in this
manner:
        ITEM<21>=ICONV(UNIT.PRICE,"MD2")

Hey, while I got the pedestal, I personally do not like printing a 4 digit
year when printing a date - (:-}.

The software package most of my customers run, DataFlo, had several
occurrences of '2' to display 2 decimal places and when they upgraded their
UniVerse to 10.n they ran into problems which I corrected simply by removing
the '2' and making sure the correct number of decimals would display
(printed form) via OCONV.

I believe IBM has corrected this issue but am not sure.

Note, I write a column in our Newsletter that's free and also is archived on
our website under the <News> tab on koretech.com.  Anyone interested in
receiving an email when the newsletter comes out (about quarterly) can send
an email to me pault<no spam>@koretech.com removing the <no spam>.

Have a Great Day!

> Paul Trebbien
> Kore Technologies, Senior Support Tech. 
> "Solutions that work. People who care."
> V 858.678.0030 F 858.300.2600 W www.koretech.com
> 


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Monday, September 20, 2004 8:37 AM
To: [EMAIL PROTECTED]
Subject: Re: [U2] Numeric rounding - UV 9.4 & 10.1


[EMAIL PROTECTED] wrote:
> I have a habbit of using the following syntax to round numbers to a
certain
> number of decimal places:
> 
> X = 1.623
> CRT X '2'
> CRT X '0'
> 
> Yields:
> 
> 1.62
> 2
> 
> It's always worked fine. Until we did an upgrade to 10.1. Now it has been
> deemed un-reliable because it produced an undesirable result (an empty
> string) in a rather sensitive program.
> 
> So, first question is:  Is this a bad habbit I've had all these years?

Yes.
> 
> Second question:  Has anyone else experienced a problem with this method
of
> rounding? Is it a known bug?

iirc, yes/no.

I seem to remember a thread on this list ages back. If you use JUST a number
as your format operator, it does not necessarily mean what you think it
does. This other thread was about it apparently producing the correct result
for ages and then suddenly going "wrong".

Basically, the number can either be interpreted as "number of decimal
places" or as "string width". That's why another poster suddenly found that
"0" returned the empty string!

iirc the manual is clear on what is the correct interpretation, but certain
implementations do/did get it wrong. As with all these things, it pays to be
explicit and not take short cuts ...

Cheers,
Wol

> -------
> u2-users mailing list
> [EMAIL PROTECTED]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to