If you’ve stumbled upon this blog and hoped it might be interesting then walk away. This blog is not interesting. It’s purely aimed at techies. If you’re not a techie involved in Oracle EnterpriseOne C-BSFN coding, this article will make you ‘C-sick’.
Right, for the few of you who are left, Oracle recently introduced a 64-bit server edition for their EnterpriseOne system. All of the standard Oracle C code has been changed to be 64-bit compliant but you will have to check / change custom C code before you can run it on the 64-bit server.
Introducing Source64 and Include64
The first thing to note is the introduction of new Source64 and Include64 folders which co-exist alongside the original source and include folders.
Note that when you snapshot into the 32-bit environment, the compiler compiles code in the ‘Source’ and ‘Include’ folders. When you snapshot into the 64-bit environment, the compiler compiles the code in the Source64 and Include64 folders.
Regardless of which environment you are in, all changes are made in the original source and include folders. When you compile or check in the C-BSFN, the objects in the 64-bit folders are automatically created and updated with some 64-bit conversions.
[Note: that there appears to be a bug in that the ‘Start BusBuild’ button in the L.H. Exit bar does not create or update code in the 64-bit folders. Use the ‘Build Business Function’ button on the Design Tools tab to make sure the 64-bit folders are updated.]
It’s also important to compile code on the server. The server may use different hardware and software from the local system so compiling on the server may lead to errors that are not found locally. Further, testing on the server is even more important with the 64-bit system. Many errors do not manifest themselves when running locally so developers should always test thoroughly on the server before handing code over for functional testing.
For some examples of the automatic conversions between 32-bit and 64-bit folder see below:-
All occurrences of ‘long’ are replaced by ‘int’ in the 64 bit folders. Note that even comments and strings with the word long will be changed so you could end up with strange error messages in your code like “Object name too int”.
Several Macros / function / API names are changed in the 64-folders.
- Sizeof becomes jdesizeof
- memset becomes jdeZMemset
- memcpy becomes jdeMemcpy
- MathNumberToLong becomes MathNumberToInt
- Etc
Changes to 64-bit Server Compatibility
As well as these automatic changes, Oracle have made many other changes to make their code compatible with the 64-bit server. Any custom code needs to go through similar changes before it can be run on the 64- server. Many of these changes will be picked up by the 64-bit compiler but some will not. Below are some of the more common changes that will need to be made to custom code.
Handle IDs and pointers cannot be passed between objects in 64-bit C. Instead, use jdeStoreDataPtr and jdeRetrieveDataPtr to pass the value.
Pointer arithmetic leading to integer results will lead to overflow. nOffset = lpszNew – lpszOld should be replaced with nOffset = jdeCast32(lpszNew – lpszOld). Alternatively, create Offset as a jdesizeV_t variable. Similarly, jdeStrncpy (szStepDesc, pStart, pEnd-pStart) can be replaced with jdeStrncpy (szStepDesc, pStart, jdeCast32(pEnd-pStart)) or with jdeStrncpyV (szStepDesc, pStart, pEnd-pStart). jdeStrncpyV is one of several new 32b/64b compliant V type calls.
Time code has changed because long does not work in 64-bit. Instead of
long lTime;
jdeLocaltime(&lTime, &dsLocalTime);
use
Time_t tTime;
jdeLocaltime(&tTime, &dsLocalTime);
These are just a few of the changes required. There are many more.
At DWS, we have performed a number of upgrades where the target system is 64-bit. We’ve learnt as we’ve gone along and have developed a range of tools which search for all known 64-bit compliant issues, saving project hours and supporting our aim to upgrade client software with zero defects.
Contact our team today to discuss your requirements.
