Most programs act the same without regard to data representation, but to ensure that this is true for your programs, you need to understand the differences described in the following sections.
The workstation compilers support options that instruct the operating system to treat data and floating-point operations the same way that the mainframe does. There are suboptions of the DEFAULT compile-time option that you should specify for all mainframe applications that might need to be changed when moving code to the workstation:
For more information on these compile-time options, see DEFAULT.
This means that code dependent on the EBCDIC hexadecimal values of character data can logically fail when run using ASCII. For example, code that tests whether or not a character is a blank by comparing it with '40'x fails when run using ASCII. Similarly, code that changes letters to uppercase by using 'OR' and '80'b4 fails when run using ASCII. (Code that uses the TRANSLATE built-in function to change to uppercase letters, however, does not fail.)
In the ASCII character set, digits have the hexadecimal values '30'x through '39'x. The ASCII lowercase letter 'a' has the hexadecimal value '61'x, and the uppercase letter 'A' has the hexadecimal value '41'x. In the EBCDIC character set, digits have the hexadecimal values 'F0'x through 'F9'x. In EBCDIC, the lowercase letter 'a' has the hexadecimal value '81'x, and the uppercase letter 'A' has the hexadecimal value 'C1'x. These differences have some interesting consequences:
Because of the differences described, the results of sorting character strings are different under EBCDIC and ASCII. For many programs, this has no effect, but you should be aware of potential logic errors if your program depends on the exact sequence in which some character strings are sorted.
For information on converting from ASCII to EBCDIC, see Using data conversion tables.
The AIX and mainframe representation is known as Big Endian (Big End In).
The Windows representation is known, conversely, as Little Endian (Little End In)
This difference in internal representations affects:
For most programs, this difference should not create any problems. If your program depends on the hexadecimal value of an integer, however, you should be aware of potential logic errors. Such a dependency might exist if you use the UNSPEC built-in function with a FIXED BINARY argument, or if a BIT variable is based on the address of a FIXED BINARY variable.
If your program manipulates pointers as if they were integers, the difference in data representation can cause problems. If you specify DEFAULT(NONNATIVE), you probably also need to specify DEFAULT(NONNATIVEADDR).
You can specify the NONNATIVE attribute on selected declarations. For example, the assignment in the following statement converts all the FIXED BIN values in the structure from nonnative to native:
dcl
1 a1 native,
2 b fixed bin(31),
2 c fixed dec(8,4),
2 d fixed bin(31),
2 e bit(32),
2 f fixed bin(31);
dcl
1 a2 nonnative,
2 b fixed bin(31),
2 c fixed dec(8,4),
2 d fixed bin(31),
2 e bit(32),
2 f fixed bin(31);
a1 = a2;
Table 1 summarizes the differences between normalized floating-point IEEE and hexadecimal:
| Specification | IEEE (AIX) | IEEE (PC) | Hexadecimal |
| Approximate range of values | ±10E-308 to ±10E+308 | ±3.30E-4932 to ±1.21E+4932 | ±10E-78 to ±10E+75 |
| Maximum precision for FLOAT DECIMAL | 32 | 18 | 33 |
| Maximum precision for FLOAT BINARY | 106 | 64 | 109 |
| Maximum number of digits in FLOAT DECIMAL exponent | 4 | 4 | 2 |
| Maximum number of digits in FLOAT BINARY exponent | 5 | 5 | 3 |
Hexadecimal float has the same maximum and minimum exponent values for short, long, and extended floating-point, but IEEE float has differing maximum and minimum exponent values for short, long, and extended floating-point. This means that while 1E74, which in PL/I should have the attributes FLOAT DEC(1), is a valid hexadecimal short float, it is not a valid IEEE short float.
For most programs these differences should create no problems, just as the different representations of FIXED BIN variables should create no problems. However, use caution in coding if your program depends on the hexadecimal value of a float value.
Also, while FIXED BIN calculations produce the same result independent of the internal representations described above, floating-point calculations do not necessarily produce the same result because of the differences in how the floating-point values are represented. This is particularly true for short and extended floating-point.
Again, for most programs this should make no difference. If your program depends on the hexadecimal value of a graphic string or on a character string containing mixed character and graphic data, use caution in your coding practices.