RE: Binary data types and some oddities

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Yeah, this way the number will be exact, where using true binary 
decimals will almost always be an approximation. Ah, well, probably 
too much time on my hands. I still wonder about the HEX() function in 
SQL. For dates and times the true internal form is returned, as I 
understand it. Time is in 3 bytes, with each digit in a nybble. Dates 
are something called Scaliger or Julian days (number of days since 
something like January 1st, 4713 B.C.). So SQL handles those 
according to their true internal representation, where "fractional" 
binary numbers are not treated the same. Curious - might call it in.

Thanks

At 10:27 PM 3/5/2006, you wrote:

> Vernon,
>
> I don't think there is anything particularly "odd" about what you are
> seeing.
>
> The B data type is converted internally (in most cases) to packed - which is
> where your 12F comes from.  Although quite why SQL shows you the packed
> version when you ask for the content in hex is anybody's guess.  But then
> SQL does a lot of odd things.
>
> Because of the packed conversion there is no need for the "funny numbers"
> (sorry "binimals") you describe - the value is simply stored as an integer
> and the scaling taken care of during conversion to packed.
>
> True Integers (U and I in RPG) can't have decimals because they don't
> implicitly get converted to packed.
>
> Simple answer is don't sweat it - as long as the system gets the right
> answer .....
>
>
> Jon Paris
> Partner400
>
> www.Partner400.com
> www.RPGWorld.com
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.