Re: Binary data types and some oddities

So that 1.2 (decimal) is stored as the binary integer twelve, or x000C.


Vernon Hamberg wrote:

Y'all

I'm working on some conversion stuff and am looking at how binary numbers work on the iSeries. I've run across some curious things.

In PDM, when I prompt a DDS spec and get help for the number of decimals, I get this:

Type a value from 0 to 31 to indicate the number of decimal positions to the right of the decimal point within a Packed Decimal, a Zoned Decimal, a Floating Point, or a Binary field.

OK, first, maximum digits for a binary through DDS is 18, for a float is 17, so this is, at best, a kind of summary statement.

But number of deimals > 0 for binary data? Yes, it can be done. I declared a field as "2B 1" in DDS. I put the value 1.2 into the field, using SQL. But now things get really strange. In base 2, proper fractions of base 10 that have a denominator other than a power of 2 will result in repeating patterns of 1's and 0's after the decimal point (an oxymoron - decimal implies base 10, eh?). I looked it up - 1/5 is .00110011... ad infinitum in binary numbers, and that looks like it's be represented in a byte as x33. So I'm thinking that 1.2 could be 00000001.00110011 (only approx. 2 - actually 1.9921975) or x0133 in 2 bytes - how many bytes should be used to represent binimals? (I made that up.)

It gets worse - in STRSQL I

INSERT INTO BINTEST VALUES(1.2)

then

SELECT * FROM BINTEST

the file has a single field, BIN2P1, as "2B 1"). It is displayed as 1.2 - nice. Then I

SELECT HEX(BIN2P1) FROM BINTEST

and it displays 012F. Oops - that is a packed field with digits 12.

Then I DSPPFM BINTEST and press F10 & F11, to see the hex values. It shows 000C, which is 12 in decimal.

BTW, SQL does not have a binary type of this variety - it has only the INT variations. So there are no issues of decimal (binimal) points.

Weird? Of course, IBM have always said the in RPG a B and an I are not the same thing.