輕松實現應用程序移植！
是否計劃將 Oracle 應用程序移植到 IBM? DB2? for
Linux?, UNIX? and Windows?？學習如何使用本文描述的
步驟完成此任務。本文包含的示例腳本可以使任務更加簡
單。
簡介
本文適用于以下開發人員、管理員或獨立軟件供應商
（Independent Software Vendor，ISV）：
擁有支持非 IBM 數據庫（比如 Oracle Server）的數據庫
應用程序
其客戶希望將 Oracle 應用程序遷移到位于分布式平臺上
的 IBM DB2 — DB2 for Linux, UNIX, and Windows（本
文中使用 DB2）
許多想遷移 Oracle 應用程序以支持 DB2 的企業和業務合
作伙伴提出了以下問題：
許多使用 Oracle 服務器的客戶都希望在 DB2 上運行他們
的應用程序。我需要進行哪些更改才能使應用程序支持
DB2 數據訪問？
只要逐步執行本文描述的步驟，就很容易將 Oracle 應用
程序移植到 DB2 平臺。本文指出了在將 Oracle 應用程序
遷移到 DB2 時可能遇到的最常見問題，同時也提供了克服
這些問題的步驟。我曾經成功對擁有 1 億行源代碼的
Oracle 應用程序進行了概念證明（proof-of-concept）遷
移，本文就是建立在這個基礎之上。
以下是針對本文的示例遷移的一些假設：
示例 Oracle 應用程序是用 C/C++ 編程語言編寫的。
在 UNIX (AIX? 5.2) 平臺上的 DB2 Version V8.2 上進行
移植。本文討論的大多數問題也適用于 DB2 9。
以下是本文將描述的問題：
DB2 預編譯器不能識別聲明部分中用戶定義的數據類型
（typefef，#define macros），位于 EXEC SQL BEGIN
DECLARE SECTION 和 EXEC SQL END DECLARE SECTION 語
句之間。
由于參數類型不同，使用用戶定義函數（UDF）（比如 ||
、rawtohex、hextoraw，等等）開發的應用程序不能在
DB2 上編譯。
使用 DECODE 函數的 Oracle 應用程序不能在 DB2 上正確
編譯。
需要在 DB2 中執行與包含 NOWAIT 的 Oracle SQL 語句類
似的行為。
需要在 DB2 中處理大小超過 32672 的主機變量。
當移植到 DB2 時，需要考慮 Oracle 的 “Select for
update” 語句。
本文將移植過程分解成一些主要任務，然后探討每個任務
涉及的問題。
任務 1：標識嵌入式 SQL（.sqC）程序
對于此任務，需要在應用程序中標識所有的 Pro C（SQL +
C/C++ 程序組合）程序。首先應該將這些 Pro C 程序轉換
為 DB2 能用其預編譯器解釋的嵌入式 SQL 程序。
SQL 與 C 程序組合：擴展名為 .sqc（在 UNIX 上）
SQL 與 C++ 程序組合：擴展名為 .sqC（在 UNIX 上）
也許還需要回顧一下用 C/C++ 開發的嵌入式 SQL 程序示
例。可以在 DB2 實例目錄下的以下路徑中找到它們：
C 程序：sqllib/samples/c
C++ 程序：sqllib/samples/cpp
這些嵌入式 SQL 程序是用 DB2 的預編譯器（db2 prep）
編譯的。
問題 1
如果在 EXEC SQL BEGIN DECLARE SECTION 和 EXEC SQL
END DECLARE SECTION 語句之間使用了用戶定義的數據類
型（例如 C/C++ 中的 “typedef”）和宏（#define），
那么 DB2 預編譯器在編譯這些程序時會遇到一些問題。
因此，如果將一個包含嵌入式 SQL 語句的文件（.sqC）傳
遞到 db2 precompile 命令，則編譯時會提示出錯。如清
單 1 所示。
注：
此示例只是為了描述問題并在編譯之后生成相應的錯誤，
所以其形式非常簡單。要重現此場景，可以執行 db2
"create table test_table (dept int)" 命令創建一個
“TEST_TABLE” 表。
考慮如下的 test1.sqC 文件：
清單 1. test1.sqC
#include <stdio.h>
#define LONGBIG long
/*
Or we can have a definition like:
typedef long LONGBIG
*/
EXEC SQL INCLUDE SQLCA;
EXEC SQL BEGIN DECLARE SECTION;
LONGBIG col1_val;
EXEC SQL END DECLARE SECTION;
int main()
{
EXEC SQL SELECT DEPT
INTO :col1_val
FROM TEST_TABLE;
return 0;
}
當試圖使用 db2 prep 編譯 test1.sqC 文件時，會得到以
下錯誤：
清單 2. 預編譯 test1.sqC 的結果
db2 prep test1.sqC bindfile
LINE MESSAGES FOR test1.sqC
------ ------------------------------------------
--------------------------
SQL0060W The "C++" precompiler is in
progress.
11 SQL0008N The token "LONGBIG" found in a
host variable
declaration is not valid.
18 SQL4942N The statement selects an
incompatible data type
into host variable ":col1_val".
SQLSTATE=42806
SQL0095N No bind file was created because
of previous
errors.
SQL0091W Precompilation or binding was
ended with "3"
errors and "0" warnings.
[db2inst1]/users/ganesh_gosavi/mig1/issues/NULL_iss
ue>
出現這些錯誤是因為 DB2 預編譯器不能解析一些 typedef
和宏，這些 typedef 和宏用于通過 EXEC SQL BEGIN
DECLARE SECTION 和 EXEC SQL END DECLARE SECTION 語
句定義的聲明部分。
問題 2
第 2 個問題與在代碼聲明部分中廣泛使用的類型定義有關
，這些類型定義包括 typedef 結構、嵌入式結構中的
typedef、用戶定義的數據類型，以及在各種嵌入式頭文件
中聲明的 typedef。
清單 3 中的示例源代碼演示了該問題。
清單 3. test2.sqC
#include <stdio.h>
#include <string.h>
.
.
EXEC SQL INCLUDE SQLCA;
EXEC SQL BEGIN DECLARE SECTION;
#include "extrndef.h"
EXEC SQL INCLUDE 'UPR_ELEMENTS.H';
EXTERN varchar b2k_amount_host_str[50][35];
static varchar cur_time[20];
static varchar cur_user[16];
static char cur_time[20];
static char cur_user[16];
EXEC SQL END DECLARE SECTION;
問題 1 和 2 的解決方案
以上問題的一個常用解決方案是，不要在 EXEC SQL 聲明
部分中使用 typedef 和宏。但是如果擁有很多這樣的文件
，手動完成此操作很麻煩，您也許希望進行自動處理。我
們在此處提供一個 Perl 腳本（esql_prep），以減少手動
操作的麻煩，該腳本使任務變得更加簡單。
注：該腳本的主要開發人員是 Knut Stolze
(stolze@de.ibm.com)。請謹慎使用此腳本，跟平常一樣，
在將其應用到源代碼中之前，請首先測試其功用。也許有
一些特殊條件未包含在腳本中，這可能會產生錯誤的結果
。
使用此 Perl 腳本的語法如下：
清單 4. Perl 腳本的語法
./esql_prep xxxxxxx.SQX "gcc -E -I<path>"
此處，
“path” 既可以是頭（.h）包含文件的相對路徑，也可以
是其絕對路徑。
“xxxxxxx.SQX” 是一個含有問題 1 和問題 2 中所描述
問題的文件。
“gcc -E” 選項告訴 C++ 編譯器對 “xxxxxxx.SQX” 文
件進行預處理。
上面的命令對 xxxxxxx.SQX 文件進行預處理，并生成一個
新文件 xxxxxxx.SQC。在 xxxxxxx.SQC 文件中可以看到，
預定義的宏和用戶定義類型已經被替換了。然后可以將
xxxxxxx.SQC 文件傳遞給 db2 prep 預編譯器執行下一步
操作。
問題 3
當將嵌入式 SQL 程序（例如，test3.sqc 或 test3.sqC）
傳遞給 db2 prep 預編譯器時，會輸出兩個文件：
一個修改過的 C 或 C++ 程序（test.c 或 test.C）
一個綁定文件（test.bnd）
當將 test3.c 或 test3.C 傳遞給語言編譯器（C/C++）時
，語言編譯器有時會返回一個與清單 5 類似的錯誤：
清單 5. test3.sqC 編譯錯誤
"test3.i",line 6043.38:1540-0274 (S)The name lookup
for "NULL" did not find a declaration.
此錯誤是由于預編譯器在創建 C 文件時插入與清單 6 類
似的語句引起的：
清單 6. 預編譯器輸出
.
.
sql_setdlist[0].sqldata = (void*)&col1_val;
#line 6043 "test3.i"
sql_setdlist[0].sqlind = 0L;
#line 6043 "test3.i"
sqlasetdata(3,0,1,sql_setdlist,NULL,0L);
}
此時發生了如下操作？
上面的 esql_prep 通過 C/C++ 預編譯器運行源代碼（仍
包含嵌入式 SQL 語句）。結果，所有的 #include 指令都
被解析了，包括 <stdio.h> 中的指令。
DB2 預編譯器插入這些語句（包含 “NULL”），如上面的
清單所示。
常規的 C/C++ 編譯器開始編譯。它執行一個常規的 C/C++
預編譯。但是預編譯不會做任何事情，因為這些都在步驟
1 中完成了。特別是，不再有 #include 指令。結果，代
碼中的 “NULL” 未被更改。C/C++ 編譯器找到 “NULL”
并報告錯誤，因為它不知道該怎么做。畢竟 “#define
NULL (void *)0” 不在此處，因為沒有找到 #include
<stdio.h>。
因此，必須為 NULL 提供一個常規的 #define。
結果，db2 prep 預編譯器返回清單 4 所示的錯誤。
問題 3 的解決方案
要消除此錯誤，可以使用編譯器的 -D 選項。
例如：
清單 7. test2.sqC
/usr/vacpp/bin/xlC -c -o test3.o -DNULL=0 -I./
-I/db2/db2inst1/sqllib/include
任務 2：在 DB2 for Linux, UNIX, and Windows 中實現
Oracle UDF 行為
這是在將 Oracle 應用程序遷移到 DB2 for Linux, UNIX,
and Windows 時面臨的主要挑戰。應用程序調用 Oracle
支持的各種 UDF。對各個文件和目錄的所有代碼（可能有
數百萬條）進行檢查是非常困難的。找到每個位置并更改
相應的源代碼，從而讓應用程序支持 DB2，這是一項單調
、麻煩且容易出錯的工作。
本文下載部分的 OracleToDB2UDFs.zip 提供了許多等價的
Oracle UDF。只需在選擇的模式下對它們進行注冊即可。
無需修改應用程序源代碼就可使用這些 UDF。