If your program uses pointers, you need to ensure that they are not redefined or modified by reference. There should also be no assumptions in your record definitions about the sizes of pointers, as the pointer size increases from 4 bytes to 8 bytes in a 64-bit environment.
To mitigate against potential problems, that usually only become apparent at run time, you should consider using call prototyping for multi-program applications. It ensures that each CALL statement is checked for correctness at compile time, and will flag situations such as when a called program is expecting a pointer of one size (for example, a 64-bit, 8-byte pointer) but is receiving the wrong sized pointer (a 32-bit, 4-byte pointer); see About Call Prototypes for more information about how to convert your existing programs to use this functionality.
To help you find invalid manipulations of the data-type POINTER in your programs, use the 64 bit readiness rule set of the code analysis tools; this can be run from the IDE or the command line.
You also need to be careful about making assumptions about the length of groups, especially when using them with information passed to and from a Micro Focus library routine. Some fields within groups can differ in size between 32-bit and 64-bit; for example, CBL_GET_PROGRAM_INFO contains the parameter block cblt-prog-info-params, which contains a length field (cblte-gpi-size) that differs in size based on 32- and 64-bit compilation. When using such groups, use the conditional compilation technique (discussed in Single Sourcing), or use the length of syntax.
If you are also using pointers with the RETURN-CODE special register, you must ensure that the size of the return code matches the size of the pointer if you place the pointer into the special register. You can do this by using the RTNCODE-SIZE Compiler directive: set it to RTNCODE-SIZE"8" for your 64-bit programs, as the default is RTNCODE-SIZE"4".