×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hi Joe,
Anyway, if you declare a field in SQL as type INT, it is actually
declared in DB2 as a 9B0 field. This is fine right up until the time
you try to write a value over 999,999,999.
I think, perhaps, you're assuming that 9B 0 in the database behaves like
9B 0 in RPG. It does not. 9B 0 in the database is a "real integer",
and does not have the 999,999,999 limit.
9B 0 in RPG does have that limit. Unfortunately, by default, RPG will
map a 9B 0 database field into the (yucky) 9B 0 RPG field, thus causing
a problem. Worse, programs generated by the UPDDTA function of DFU
will generate RPG code that uses this awful 9B 0 data type.
however, the database 9B 0 can store values up to the full 32 bits, like
a true integer field. If you code EXTBININT(*YES) on your RPG H-spec,
the RPG compiler will use true integers when it reads/writes the file as
well, thus providing full integer support all around. (Unfortunately,
for backward compatibility, EXTBININT(*YES) is not the default)
To try it out... create the following PF (I used DDS instead of DDL
because it makes it clearer that it's a 9B 0 field):
A R INTFILEF
A FIELD1 9B 0
Then insert a value higher than 999999999:
insert into INTFILE values(1999999999)
Then try reading that value from RPG:
H EXTBININT(*YES)
FINTFILE IF E DISK
/free
read INTFILE;
dsply (%char(field1));
*inlr = *on;
/end-free
It should display the full value, because of the EXTBININT. Remove the
EXTBININT, and it will no longer show the full value.
midrange.com
