Numeric types

EGL provides a variety of numeric data types. Some of the numeric types (such as BIGINT or FLOAT) automatically indicate the length and decimal places. For other numeric types (such as BIN or DECIMAL), you must specify the length and (if appropriate) the number of decimal places, as in the following example:

truckMileage BIN(9,2);             // 9 digits, two decimal places
DataItem zipCode INT
  { validValues = [00000,99999]};  // 5 digits only
myZipCode zipcode;	

EGL allocates storage for truckMileage and myZipCode, but not for the zipCode data item, which is only a model.

Table 1. EGL primitive numeric types
Primitive Size Specify length Decimals Data type DB2® equivalent
BIGINT 18 digits (8 bytes) N N binary BIGINT
BIN 4, 9, or 18 digits (2, 4, or 8 bytes) Y Y binary n/a

18 or 31 digits COBOL
32 digits JAVA

Y Y packed decimal characters DECIMAL
FLOAT 18 digits (8 bytes) N Y double-precision floating point FLOAT
INT 9 digits (4 bytes) N N binary INTEGER

18 or 31 digits COBOL
32 digits JAVA

Y Y packed decimal characters DECIMAL
NUM 31 digits Y Y numeric characters (zoned decimal) NUMERIC
NUMC* 18 digits Y Y numeric characters (zoned decimal) NUMERIC
PACF* 18 digits Y Y packed decimal characters DECIMAL
SMALLFLOAT 9 digits (4 bytes) N Y single- precision floating point REAL
SMALLINT 4 digits (2 bytes) N N binary SMALLINT

*NUMC and PACF available only in VisualAge® Generator compatibility mode.

The following considerations apply to numeric types:
  1. All maximum lengths given in digits are approximate—for example, the maximum value you can store in two bytes while keeping one bit available for a sign is +32,767 or -32,768. You can safely store any four digit number in two bytes, so the table shows the maximum length as 4 digits.
  2. The three sizes of BIN (4, 9, and 18 digits) correspond to SMALLINT, INT, and BIGINT respectively, and are the only permitted sizes for BIN variables. The difference between a variable declared as BIN(4,2) and one declared as INT is that the BIN variable has two decimal places. An INT variable has no decimal places.
  3. You can store a 32-digit number in a DECIMAL or MONEY variable in Java™. In COBOL, the maximum length is either 18 or 31 digits, depending on the value of the maxNumericDigits build descriptor option. Also, 31 digits are the maximum for DB/2.
  4. In EGL-generated Java programs, the value of a FLOAT variable ranges from 4.9e-324 to 1.7976931348623157e308. In EGL-generated COBOL programs on z/OS®, the value ranges from 5.4e-79 to 7.2e+75. In EGL-generated COBOL programs on iSeries®, the value ranges from 2.225074e-308 to 1.797693e+308.
  5. In EGL-generated Java programs, the value of a SMALLFLOAT ranges from 3.40282347e+38 to 1.40239846e-45. In EGL-generated COBOL programs on z/OS, the value ranges from from 5.4e-79 to 7.2e+75. In EGL-generated COBOL programs on iSeries, the value ranges from 1.175494e-38 to 3.402823e+38. Note that the range of values on z/OS is the same for both FLOAT and SMALLFLOAT. The difference between the two types is in the size of the mantissa (also called the significand): 6 hexadecimal digits for the SMALLFLOAT (at least 7 decimal digits) and 14 hexadecimal digits for the FLOAT (at least 17 decimal digits).
  6. MONEY is identical to DECIMAL except that, when you output a variable based on MONEY, EGL uses the strLib.defaultMoneyFormat system variable to determine the output format. By default this format has two decimal places and includes a currency symbol.
  7. EGL supports the NUMC and PACF types so you can work with files and databases from older applications. In new development, use variables and fields based on BIN or an equivalent integer type (BIGINT, INT, or SMALLINT), or on the DECIMAL type; calculations are more efficient with those variable types. You get the greatest efficiency by using four-digit BIN variables with no decimal places (the equivalent of the SMALLINT type).
  8. Other efficiency considerations include the following points:
    • In calculations, assignments, and comparisons, NUM fields that have no decimal places are more efficient than those that do have decimal places.
    • For code generated in Java, calculations with DECIMAL, NUM, NUMC, and PACF fields are equally efficient. For code generated in COBOL, however, these distinctions apply:
      • Calculations with NUM fields are more efficient than calculations with NUMC fields.
      • Calculations with DECIMAL fields are more efficient than calculations with PACF fields.
  9. If you are new to mainframe computing, you might not recognize two common types of numeric variables in COBOL: zoned decimal and packed decimal. If you work with these types, your EGL data types must match the format and sign configuration of the data these types contain. Here is a quick overview:
    • EBCDIC represents ordinary positive numbers 0-9 with hex characters F0-F9 (for example, 150 translates to F1F5F0). COBOL also supports "zoned" data types that allow signs (in EGL these are NUM and NUMC). The rightmost hex digit carries the sign for the whole number, with a D replacing the F for a negative number. Thus F1F5D0 translates to -150. In the case of NUMC, a C replaces the F for a positive number, rendering positive 150 as F1F5C0.
    • The repeated F characters may seem redundant to those unfamiliar with EBCDIC. Packed decimal data types (represented in EGL by DECIMAL, MONEY, and PACF) eliminate the redundancy. The packed decimal version of -150 is 150D. Positive 150 is 150, except in the PACF format, where it would be 150F.

Compatibility considerations

Table 2. Compatibility considerations
Platform Issue
JavaScript generation The following types are supported: ANY, BIGINT, BIN (but only in the absence of decimal places), Boolean, DataItem, DATE, DECIMAL, Delegate, Dictionary, FLOAT, INT, NUM, NUMBER, SMALLFLOAT, SMALLINT, STRING (but only in the absence of a size limit) , TIME, TIMESTAMP, NUM, MONEY, Service parts, Interface parts, External types (stereotype JavaScript), arrays of supported types, and non-structured Basic, Exception, and SQL Record parts.

The following types are not supported: ArrayDictionary, BIN (with decimal places), BLOB, CHAR, CLOB, DBCHAR, HEX, INTERVAL, MBCHAR, NUMC, STRING (with a size limit), PACF, UNICODE, and structured Record parts.