Upgrading 32-bit external routines to run on 64-bit instances

Upgrading your existing 32-bit external routines to a DB2® Version 9.7 64-bit instance involves managing the changes between DB2 Version 9.7 and previous releases that impact these routines and verifying that these routines function as expected.

1. Ensure that the library path environment variables include the correct DB2 shared library path for 32-bit libraries as shown in Table 2, so that the correct library can be loaded at runtime.
2. Test your routines in a DB2 Version 9.7 testing environment. If testing is successful, you do not need to perform any additional steps. However, consider performing the remaining steps in this task if they apply to your routine for better support by using the correct library path and development software.
3. Specify the correct library path by linking or rebuilding your 32-bit external routines using the DB2 shared library paths for 32-bit libraries shown in Table 1. If you upgraded from a DB2 UDB Version 8 32-bit instance to a DB2 Version 9.7 64-bit instance, you must rebuild 32-bit external routines that use LOB locators as 64-bit routine libraries.
4. Optional: If you no longer have the source code to rebuild your routine library or you cannot use environmental variables, use the db2chglibpath command to change the DB2 shared library path to $INSTHOME/sqllib/lib32 on your routine binary file as long as it has an embedded runtime path. The embedded runtime path can be changed to a new path with the same length or less.
5. Perform any other steps in the Upgrading C, C++, and COBOL routines task that apply to your routines.
6. Determine if the external routines that were altered during database upgrade or the external routines that use the DB2 engine libraries can safely run as NOT FENCED and THREADSAFE. If you have external unfenced routines in your database, the UPGRADE DATABASE command performs the following actions:
   • Returns the SQL1349W warning message and writes the ADM4100W message to the administration notification log.
   • Redefines all your external unfenced routines that have no dependency on the DB2 engine library as FENCED and NOT THREADSAFE.
   • Creates a CLP script called alter_unfenced_dbname.db2 in the directory specified by the diagpath database manager configuration parameter to redefine the affected routines as NOT FENCED and THREADSAFE.

   If you can safely run the external routines altered by database upgrade as NOT FENCED and THREADSAFE, you can redefine them as NOT FENCED and THREADSAFE using the original CLP script or a modified version with just specific routines that you want to redefine. If you can run them as FENCED and NOT THREADSAFE and the performance degradation that you experience is acceptable, you do not need to redefine your routines .