Making sense of integer representation in RPG code

There seems to be an increased use of integer data types in RPG code, as well as in D specs to define work fields. However, Steve Croy points out that not everybody understands the nature of integer data types.

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

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).

0001.00 D binint          ds                 
0002.00 D   binfield              1      4b 0
0003.00 D   bininteger    S             10i 0

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.

    int        scale = 10;
    int        maxLabelWidth = 0;

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

0021.00 D TotDiff         s             10i 0

0292.00   IF TotDiff > 99999 or TotDiff < -99999; 
0293.00      Iddlyh = 99999;                 
0294.00   ELSE;                              
0295.00      Iddlyh = TotDiff;               
0296.00   ENDIF;                             

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.


This was first published in August 2005
This Content Component encountered an error

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchEnterpriseLinux

SearchDataCenter

Close