RE:4b vs 10i (was API QIMGCVTI )

>Have you found a specific issue with 4B values? I never use them and
>haven't for years, but I've been under the impression that they can be
>used interchangably with 10i0 values provided the numeric range isn't
>outside the scope of the variable.

You're right on Bob.

For the archives, I work with telephone switches and other non-IBM sources
of data.  Only IBM has a concept of defining a number by the number of
digits (fixed length); everybody else uses a scheme directly tied to the
hardware.  Typically (but not always) it goes something like this:

smallint = 2 to the 15 = 32,768 = 2 bytes
int = 2 to the 31 = 2,147,483,648 = 4 bytes
bigint = 2 to the 63 = 9.22 x 10 to the 18 = 8 bytes

The issue is that most RPG folks automatically go for "4b 0" when they want
a four byte binary number.  Alas, that 4b turns into a nine digit maximum
fixed number: 999,999,999.  The other platform can send me numbers as large
as 2,147,483,648, so clearly stuff gets lost.

The problem with truncation is that it's subtle.  Code that has worked for
many years suddenly produces odd results; results that accumulate over time
until finally at the end of the month, the profit report shows bizarre
numbers which are traced back to daily imports that have been dropping the
high order digit.  Now I get to go back and re-import all that data and
essentially re-run the whole month.  This is basically the same problem with
defining "work" fields the smallest possible size in order to "save memory."
We've all seen that 3,0 loop counter fall apart when we bump the array to
5000 instead of 500.  This is no different.  4b 0 saves one digit in memory
compared to 10i.

>From my particular view, it's a values issue.  If the cell towers have ID
numbers from 1 to 10, then 4b works great.  When the cell company builds a
new set of towers in another county and decides to number them 1,000,000,001
- 1,000,000,005 in order to make them stand out, then that working code is
busted.  My particular situation is that somebody else determines the
maximum value: not me.

If your code never gets data from external sources and never counts higher
than the 4b limit, then sure, 4b is fine.  But I automatically recommend
that people use 10i, because that 4b is like a CHAIN without checking the
indicator.  Moving to the 10i costs nothing and the code becomes compliant
with external data sources and APIs.  There is only one place where you
cannot use 10i, and that's when the binary variable has decimals, like 4b 2.
But I have never seen that in a production database.
  --buck