by Dave Harrison

Your Oracle JD Edwards EnterpriseOne system has supported 64-bit hardware and operating systems for many years. Some of the JDE components, such as the JAS/HTML server, the AIS server and Orchestrator Studio are already 64-bit enabled. However, there remained a few key components, namely the Enterprise Server, Deployment Server and Development Client which only supported a 32-bit architecture. Starting with Tools Release 9.2.3, and further enhanced with 9.2.4, that has now changed and it is now possible to move your JDE system entirely to 64-bit processing.

Why is this important?

Hardware and software vendors are gradually phasing out support for 32-bit architectures. Embracing 64-bit will not only future-proof your investment in your JDE system but also allow you to adopt the latest technology. If you do not move to 64-bit, then you could run the risk of potential hardware or software obsolescence. Based on testing undertaken by Oracle, you should also see your interactive application response times and batch processing runtimes improve due to the enhanced performance characteristics of 64-bit processing.

So what’s involved in moving to 64-bit?

The move to 64-bit is a technical uplift, and does not affect your business processes or business data. While 64-bit processing is not mandatory, Oracle recommends that all customers create plans to transition to 64-bit processing, and during an upgrade is an ideal time to consider this since 64-bit is only supported on Application Release 9.2.

Enabling 64-bit is similar to upgrading to a new Tools Release, and, as with any Tools Release upgrade, Oracle recommends that you have multi-foundation configured to allow you to test 64-bit without affecting your production environment. While there is no impact on spec-based objects, such as tables and applications, additional consideration must be given to customizations to C Business Functions. Oracle has gone to considerable lengths to ensure that the standard JDE code is 64-bit compliant. However, changes may be needed to any new custom C functions or modifications to standard C functions, otherwise some serious run-time issues can arise.

Fortunately, Oracle provides a utility to convert C business functions from 32-bit to 64-bit. This conversion utility is called whenever the function is checked-in to the Deployment Server, as well as during package builds and ESU deployment. However, DWS’s experience of migrating these C functions to 64-bit has shown that there are still a number of coding issues that are not catered for by the standard conversion utility.

To help identify the lines of code which can cause issues, DWS has created a search string using regular expressions (regex). Using a powerful search tool, we are able to take this long regular expression string and run it over the C function code looking for lines of code that need to be reviewed by the developer.

Here is an example of a serious 64-bit coding issue:

long hFile=(long)NULL;

Under 32-bit, this statement works fine since the long variable can handle numbers up to 32-bits in size. But under 64-bit, if the memory assigned to this file handle is in the 64-bit memory area, then the value cannot be stored correctly, and any references to it will be invalid. To be 64-bit compliant, then this line needs to be replaced with:

intptr_t hFile = 0;

There are also some JDE APIs (low-level system functions) which are no longer supported by the latest Tools Releases, and these are also highlighted by our search string.

DWS has also created its own code conversion utility which we run over the C business functions during an upgrade. This utility is a 32-bit to 64-bit C code checker which performs basic checks on various JDE API statements, and ensures that obsolete APIs, common coding mistakes and incorrect usages are highlighted for the developer to check. Note that even though a function compiles correctly, this does not mean that everything has been coded correctly for 64-bit, and this utility will help to identify those situations. It also tests for possible memory leaks due to bad coding, such as when a structure has been allocated memory, but that memory is not subsequently released.

Approximately 90% of the checks that are performed are soft-coded and controlled by a ‘rules’ table, so we can easily add new code statement checks, or turn checks off where appropriate. The conversion utility has been integrated into the DWS Upgrade Workbench to enable these coding issues to be reported during the upgrade process.