I have noticed an increase in the use of integer data types in RPG code, not only in procedure prototypes, but even creeping into D specs to define work fields. The emergence of integer data types may be generally attributed to two factors.
One major factor, of course, is the increasing use of interfaces to C or Java, which necessitate using integer representations, since neither language supports fixed-format decimal representations.
The other factor is an increase in the number of system APIs finding their way into RPG programs, where the use of integers as parameters has been a practice for many years.
In past releases of OS/400, it was common to represent integer data as 4B 0 fields (4 byte binary integer). Many of the IBM API manuals still reference a 2- or 4-byte binary representation, such as this example showing the List Job Log (QMHLJOBL) API required parameter group.
Table 1
Required Parameter Group:
1
Qualified user space name
Input
Char(20)
2
Format name
Input
Char(8)
3
Message selection information
Input
...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
');
// -->

Char(*)
4
Size of message selection information
Input
Binary(4)
5
Format of message selection
information
Input
Char(8)
6
Error code
I/O
Char(*)
Now it is becoming common to see integer variables defined on D specs. The following RPG D spec example shows typical representations of integer variables (a 4-byte binary integer).
Typically an integer is analogous to one of the primitive data types found in other languages such as C and Java, like the Java variable definitions of the integer type, which is illustrated below.
I have no objection to integers being used in procedure prototypes, or any other place within an RPG application, but since I have had to address several problems where programmers were attempting to assign integer values to fixed decimal representations, it is apparent not everybody understands the nature of integer data types.
Table 2 lists Java integer representations. The variable type of INT corresponds to the integer definition on the RPG D specs above. Note the minimum and maximum values each integer type may represent.
Table 2
type
size(bits)
default value
minimum value
maximum value
byte
8
0
-128
+127
short
16
0
-32768
+32767
int
32
0
-2147483648
+2147483647
long
64
0
-9223372036854775808
+9223372036854775807
Table 3 shows a list of the values consistent with the DB2 database representations of integer data types. Though IBM integer type terminology varies somewhat from the Java primitive type designations, where SMALLINT corresponds to short integer and BIGINT corresponds to long integer representation, the value representation is the same. (IBM does not support the byte type integer representation.)
Table 3
type
size(bits)
default value
minimum value
maximum value
SMALLINT
16
0
-32768
+32767
INTEGER
32
0
-2147483648
+2147483647
BIGINT
64
0
-9223372036854775808
+9223372036854775807
Referring to either table, you can see the numeric value represented by an integer (INT/INTEGER) data type can range from -2,147,483,648 to +2,147,483,647. Even though the integer length may be represented as 4 bytes (32 bits), the precision extends to 10 digits. A 4-byte integer may represent a much larger numeric value than a 4-byte fixed decimal field.
I have had to revise ILE applications where a developer has used integer values for parameters in a procedure prototype, and after invoking the procedure the returned integer value has been assigned to a fixed (packed or zoned) decimal field. In many instances there was no check of the value or monitor block surrounding the assignment.
The attempt to add or set the value of a fixed decimal field from an integer value can lead to a decimal overflow error, receiver to small to represent value. If the assignment operation is not nested in a monitor block, the application program will give the operator no option but to cancel the program.
If the intent of a program operation is to move integer values into fixed decimal fields, steps should be taken to ensure that the integer value does not exceed the minimum and maximum values for the fixed decimal field.
Sample 1
The code in Sample 1 shows IDDLYH, a 5-digit, zero decimal position, field, assigned a value from the field TOTDIFF. The field, TOTDIFF, happens to be defined as an integer. The simple assignment IDDLYH = TOTDIFF is enough to lead to problems in the program.
The largest value you can represent in a 5-digit fixed decimal field (with no decimal positions) is 99,999. As you can see from the tables, a 4-byte integer may contain a value as large as 2,147,483,647, which cannot be represented in a 5-digit, fixed decimal field. The problem is obvious: You cannot put 10 pounds of fertilizer in a 5-pound bag (organic or otherwise).To prevent the overflow error, test the integer value prior to assignment and avoid the situation that produces the overflow. Ideally, you would then code a routine within the application to report the overflow/exception.
Avoid the decimal overflow condition with program logic. If integers are used for calculations or parameters, and the value of integer may be assigned to a fixed numeric field, either make sure the fixed decimal field is large enough to contain the integer value or test the value of the integer against the minimum/maximum value of the receiving field prior to assigning the value.
Note: There is a compiler option to tell the program to ignore the numeric overflow when running the program. But this option does not apply to results of calculations performed within expressions, thus you may still get overflow errors even when TRUNCNBR(*YES) was specified on the CRTBNDRPG command.)
-------------------------------
About the author: Steve Croy is a programmer at USXpress Enterprises Inc. in Chattanooga, Tenn.