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

Buck I agree with you 100%.

Just two subtle comments.

1)  A 4B0 field is a 2-byte binary field (same as 5i0) You have to
declare it as 9B 0 to get it to be a 4-byte binary. Which to me is
confusing enough to avoid the "B" data-type indefinately!!!

And

2) Using decimal percision with the "B" data type is just crazy, I
think. If you can't use a packed field for that, then there may be a
design issue. (Not argueing with you, just emphysizing your point.)

On another note, the use of packed and zoned fields for "work" fields
where decimal point percision is not needed it passé. RPG Developers
should move away from declaring a field as 5P0 or 7P0 or whatever, and
using 10I0 as the default work-field. If 10I0 isn't good enough use
20I0, although you can't store 20i0 in the database. :(

Then for database files that have either 5i0 or 10i0 fields represented
as 4B0 and 9B0 fields, use the EXTBININT keyword on the headerspec to
allow RPG IV to map those fields into Int field in the program.

Bob Cozzi


-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On Behalf Of Buck Calabro
Sent: Friday, December 13, 2002 11:52 AM
To: rpg400-l@midrange.com
Subject: 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
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@midrange.com To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.