Upgrading your existing C, C++, or
COBOL routines to DB2® Version 10.5 involves managing the changes between DB2 Version 10.5 and previous releases that impact these routines and
verifying that they function as expected.
Before you begin
- Ensure that you have access to a DB2 Version 10.5 server, including instances and databases. The DB2 server can be part of a testing
environment.
- Ensure that the C, C++, or COBOL routine development software
are at a version level that is supported by DB2 database products by reviewing the following
requirements:
- Ensure that you have the necessary authorizations
and privileges to use the ALTER FUNCTION or ALTER PROCEDURE statements.
The authorizations allowed are listed in the SQL
Reference Volume 2.
- Perform the previous steps in the upgrading routines task.
Restrictions
This
procedure only applies to external routines programmed in C/C++, and
COBOL (procedures only).
Procedure
To upgrade a C, C++, or COBOL routine to DB2 Version 10.5, do the following:
- If you upgraded to a DB2 Version 10.5 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 DB2 Version 10.5 64-bit instanceRoutine 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 10.5 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 10.5 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.
|
If none of the previously mentioned situations apply, you
do not need to change your routine libraries or routine definitions.
- 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.
- For routines that you did not rebuild
but that you modified, rebind the routine
packages to the target DB2 database.
- 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 .
What to do next
After upgrading your C, C++, or
COBOL routines, perform the remaining steps in the upgrading routines task.