Binary data types and some oddities

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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.