“Don’t fix it if it ain’t broke,“ is the mantra of many successful IT managers. Their goal is simple: minimize risk, manage costs, and eliminate unnecessary headaches. One of the best ways to accomplish this is to minimize the change that complex and strategic applications are exposed to. However, life is not that easy. Sometimes, no matter how much you try and avoid it, change is forced on you.
64-bit technology falls into this category. Although it has been around for many years, 64-bit technology is now forcing its way into enterprise systems and distributed applications built with CORBA, Entera/NXTera, and other older middleware platforms. Previously, some companies made the transition when they moved to a new operating system or upgraded their hardware but many companies, who had complex systems with compatible external dependencies, postponed the transition to 64-bit technology. The reason? “32-bit works fine; let’s not create work for ourselves.” However, vendor changes to operating systems and database libraries are forcing managers to face the music. As a result, there will be more full system recompilations of legacy systems than most prudent IT managers would like.
These projects can be more complex and demanding than they seem. Databases are the primary culprit because they are now ending support for several legacy databases and associated client libraries. For example, Oracle is limiting the availability of 32-bit client libraries while vendors, like IBM and Sybase, are completely phasing out the 32-bit versions of their databases in favor of 64-bit. They still package the 32-bit libraries in new releases for compatibility but they are not delivering the 32-bit versions of the database utilities. These changes are forcing the user to upgrade.
Why is this a big deal? Applications with custom interfaces that communicate with database libraries need to be re-compiled for 64-bit because the database utilities that provide functionality for compiling and testing in 32-bit are no longer available. In most cases, a 64-bit machine is required to install new versions even though 32-bit compatibility is provided.
As a result, IT managers are being forced to recompile and migrate applications and code (some of it decades old) to 64-bit architecture in order to upgrade their databases to the supported versions. This is not a problem if you have the sources for all the miscellaneous pieces, the make files still work, and you have a team that knows how to do what needs to be done. If you have problems, you may want to reach out to someone that can help. We have helped several companies using Entera and NXTera transition from 32-bit to 64-bit in 2012 and are well positioned to do more.
In upcoming posts we will discuss best practices and what to do when you’ve lost your source code.