Upgrading C, C++, and COBOL routines

Upgrading your existing C, C++, or COBOL routines to DB2® Version 9.7 involves managing the changes between DB2 Version 9.7 and previous releases that impact these routines and verifying that they function as expected.

To upgrade a C, C++, or COBOL routine to DB2 Version 9.7, do the following:

1. If you upgraded to a DB2 Version 9.7 64-bit instance, change your routine libraries or routine definitions according to the following table:

   Table 1. Upgrading C, C++, and COBOL routines to a Version 9.7 64-bit instance

   Routine definition	Action
   unfenced 32-bit routine library that use the DB2 engine library	Rebuild the routine source code into a 64-bit library using the DB2 Version 9.7 bldrtn script and redeploy the library to the DB2 server. If LOB locators are referenced in the routine, you must rebuild your routines. You can determine most of the routines that reference lob locators by executing the following query: SELECT DISTINCT a.routineschema, a.routinename, a.specificname FROM syscat.routines a, syscat.routineparms b WHERE a.specifIcname = b.specificname AND b.locator = 'Y' AND a.fenced = 'N' An advantage of this approach is that using a 64-bit library results in better routine runtime performance than using a 32-bit library.
   fenced 32-bit routine library	Rebuild the routine source code into a 64-bit library using the DB2 Version 9.7 bldrtn scripts and redeploy the library to the DB2 server. If you cannot rebuild your routines, define the routine as not threadsafe using the ALTER PROCEDURE or ALTER FUNCTION statement with the NOT THREADSAFE clause.
   upgraded from a Version 8 32-bit instance (AIX® and Windows)	You should specify a library entry point for any routine that relies on a default entry point using the ALTER PROCEDURE or ALTER FUNCTION statement. For example, to explicitly specify the entry point for an existing procedure use the following statement: ALTER SPECIFIC PROCEDURE schema-name.specific-name EXTERNAL NAME 'library-name!function-name' where library-name is the library to be loaded and function-name is the explicit entry point for the function associated with the routine.

   If none of the previously mentioned situations apply, you do not need to change your routine libraries or routine definitions.
2. If you are using the cursor blocking and found any differences in the behavior of your C, C++, or COBOL routines, review the Upgrading embedded SQL applications task to learn how to manage those differences.
3. For routines that you did not rebuild but that you modified, rebind the routine packages to the target DB2 database.
4. 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 .