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:

The change in allocation size of pointer data items and index data items between 32-bit mode and 64-bit mode programs, described above, affects the layout of group items. In particular, data items that are located after a pointer or index data item could be located at different offsets within a group. Also, the number of slack bytes (bytes inserted by the compiler to ensure correct alignment) could differ, and thus the total size of a group could change.
Restriction: Your COBOL programs should not rely on the 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.

Restriction: CICS® TXSeries® supports only 32-bit COBOL applications.

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.