Migration of 32-bit applications to 64-bit mode
Execution results can change in 64-bit mode. If you migrate 32-bit applications to 64-bit mode, you might need to do some recoding to accommodate the differences.
Although the main consideration in migrating to 64-bit mode is the change in size of data items, other areas of an application could potentially be impacted, as described below.
LENGTH OF
special register:
In
32-bit mode, the implicit definition of the LENGTH OF
special
register is PICTURE 9(9) USAGE IS BINARY
. In 64-bit
mode, the implicit definition is PICTURE 9(18) USAGE IS BINARY
.
LENGTH
intrinsic function:
In
32-bit mode, FUNCTION LENGTH
returns a 9-digit integer.
In 64-bit mode, it returns an 18-digit integer.
Address data items and index data items:
The storage allocation for data items that contain addresses or indexes is 4 bytes in 32-bit mode, and 8 bytes in 64-bit mode. The data items that are affected are those that are defined with any of the following usages:
POINTER
FUNCTION-POINTER
PROCEDURE-POINTER
INDEX
The special register
ADDRESS OF
is implicitly
defined as USAGE POINTER
. Therefore storage is allocated for
it as described above for USAGE POINTER
data items.
Layout of group items:
SYNCHRONIZED
data items:
If the SYNCHRONIZED
clause is specified for pointer data items
or index data items, the items are aligned on a fullword boundary in 32-bit mode and on a doubleword
boundary in 64-bit mode.
Because the size of pointers is different between 32-bit and 64-bit applications, the
offsets of data items that are subsequent to them in a group, as well as the overall size of the
group, will change. This is true regardless of whether or not slack bytes are inserted by the
compiler when SYNCHRONIZED
is specified. However, specifying
SYNCHRONIZED
will further affect the offsets of pointers and subsequent data items
in a group, as well as the group size due to the difference in the alignment for pointers between
32-bit and 64-bit applications.
Redefining pointer data items:
Because the size of a pointer is different between 32-bit and 64-bit applications, using it as the object of a REDEFINES clause might yield undesired results unless the size of the redefining data item (that is, the REDEFINES subject) is also changed accordingly. However, even if you change the redefining data item to match the size of the pointer, carefully consider why you are redefining a pointer in the first place. The value of a pointer is an address and generally speaking your program should only use pointers in the COBOL statements that explicitly support using pointers such as the SET statement. Using a REDEFINES clause to inspect or set the value of a pointer is not recommended.
Using the IGY-ADDR conditional compilation variable
In general, it is recommended that you code your programs so that they are not affected by the switch from 32-bit to 64-bit applications. For example, there is no dependency on the layout of data items in a group if you code your programs in this way.
However, if for some reason your programs are sensitive to the addressing mode, there is a predefined conditional compilation variable named IGY-ADDR, which can be used to have different code paths compiled based on the setting of the ADDR option. This allows you to maintain a single source file that will work for both 32-bit and 64-bit compilations.
Data files:
Data files created by 32-bit mode programs can be processed by 64-bit mode programs, and data files created by 64-bit mode programs can be processed by 32-bit mode programs. No addressing mode is attached to a data file. However, if a record definition contains an address data item or index data item, migration to 64-bit mode could cause the length of the record, and thus the length of the file, to change.
Middleware subsystems:
If a program depends on a middleware subsystem to do data-processing tasks, make sure that that subsystem works with 64-bit programs.
DB2® Version 11.5 supports either 32-bit or 64-bit COBOL applications.
Other considerations:
Linux® does not support mixing 32-bit mode and 64-bit mode programs within an application, and the linker does not support linking object files of different addressing modes. If a 64-bit program makes interlanguage calls, or calls routines in a user library, make sure that 64-bit versions of the called routines are available.