Binary data types and some oddities -- MIDRANGE-L

Y'all

I'm working on some conversion stuff and am looking at how binarynumbers 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 ofdecimals, I get this:

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

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

But number of deimals > 0 for binary data? Yes, it can be done. Ideclared a field as "2B 1" in DDS. I put the value 1.2 into thefield, using SQL. But now things get really strange. In base 2,proper fractions of base 10 that have a denominator other than apower of 2 will result in repeating patterns of 1's and 0's after thedecimal point (an oxymoron - decimal implies base 10, eh?). I lookedit up - 1/5 is .00110011... ad infinitum in binary numbers, and thatlooks like it's be represented in a byte as x33. So I'm thinking that1.2 could be 00000001.00110011 (only approx. 2 - actually 1.9921975)or x0133 in 2 bytes - how many bytes should be used to representbinimals? (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 as1.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. Itshows 000C, which is 12 in decimal.

BTW, SQL does not have a binary type of this variety - it has onlythe 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 arenot the same thing.