DB2 コネクトにより、アプリケーション・プログラムは、 System/390 サーバーと AS/400 サーバー上にある DB2 データベース内のデータにアクセスできます。 たとえば、Windows の下で実行されているアプリケーションは DB2 ユニバーサル・データベース (OS/390 版) データベース内のデータにアクセスできます。 新規のアプリケーションを作成することもできますし、 既存のアプリケーションをホストまたは AS/400 環境で実行できるように修正することもできます。 ある 1 つの環境でアプリケーションを開発し、それを別の環境に移植することもできます。
DB2 コネクトを使用すれば、DB2 ユニバーサル・データベース (OS/390 版) のようなホスト・データベース製品で以下の API が利用できるようになります。 ただし使用できるのは、その項目がホスト・データベース製品によりサポートされている場合に限られます。
SQL ステートメントの中には、関係データベース製品によって相違のあるものもあります。 使われる SQL ステートメントは以下のように分類できます。
はじめの 2 つの類別の SQL ステートメントは可搬性が高いですが、 3 番目の類別の SQL ステートメントはまず変更を行うことが必要な場合があります。 一般的に、データ定義言語 (DDL) での SQL ステートメントは、 データ操作言語 (DML) での SQL ステートメントほど可搬性が高くありません。
DB2 ユニバーサル・データベースではサポートされていない SQL ステ ートメントでも DB2 コネクトには受け入れられるものがあります。 DB2 コネクトはこれらのステートメントをホストまたは AS/400 サーバーに渡します。 最大列長のような別のプラットフォームの制限に関する情報は、 SQL 解説書 を参照してください。
CICS アプリケーションを OS/390 または VSE から他の CICS 製品 (たとえば CICS (AIX 版) ) の下で実行するよう移植する場合には、 DB2 コネクトを使用して OS/390 または VSE のデータベースにアクセスすることもできます。 詳細については、 CICS/6000 適用業務プログラミングの手引き および CICS カストマイゼーションおよび操作 を参照してください。
ホストまたは AS/400 環境でプログラミングを行う場合は、 以下に挙げる要因に特に注意してください。
異なるシステムでは記憶域の扱われ方が異なるので、 DDL ステートメントは IBM データベース製品により異なります。 ホストまたは AS/400 サーバー・システムでは、 データベースの設計と CREATE TABLE ステートメントの発行の間にいくつかのステップがあり得ます。 たとえば、一連のステートメントによって、論理オブジェクトの設計を、 それらのオブジェクトの記憶域内での物理的表現へと変換する場合があります。
ホストまたは AS/400 サーバー・データベースへのプリコンパイルを行うさいに、 プリコンパイラーはそのような多くの DDL ステートメントをホストまたは AS/400 サーバーに渡します。 その同じステートメントは、 アプリケーションが実行されているシステム上のデータベースに対してはプリコンパイルを行いません。 たとえば、OS/2 アプリケーションにおいて、 CREATE STORGROUP ステートメントは DB2 ユニバーサル・データベース (OS/390 版) データベースに対しては正常にプリコンパイルされますが、 DB2 (OS/2 版) データベースに対しては正常にプリコンパイルされません。
一般的に、DML ステートメントには高い可搬性があります。 SELECT、 INSERT、UPDATE、および DELETE ステートメントなどは、IBM 関係データベース製品の間で類似しています。 ほとんどのアプリケーションは主に DML SQL ステートメントを使用しています。 それらは DB2 コネクト・プログラムによりサポートされています。
数値データが DB2 ユニバーサル・データベース に転送されると、データ・タイプが変わることがあります。 (DB2 ユニバーサル・データベース (AS/400 版) によってサポートされる) 数値およびゾーン 10 進の SQLTYPE は、 固定 (パック) 10 進の SQLTYPE に変換されます。
混合バイト・データは、拡張 UNIX 文字セット (EUC) の文字、 2 バイト文字セット (DBCS) の文字および 1 バイト文字セット (SBCS) の文字が同じ列の中で構成されています。 データを EBCDIC で保管するシステム (OS/390、 OS/400、VSE および VM) では、 2 バイト・データの始まりと終わりはシフトアウト (SO) 文字およびシフトイン (SI) 文字で印付けられます。 データを ASCII で保管するシステム (OS/2 および UNIX など) では、 シフトイン文字およびシフトアウト文字は必須ではありません。
アプリケーションで混合データを ASCII システムから EBCDIC システムへ転送する場合は、 シフト文字のための十分な余地を確保するようにしてください。 SBCS データから DBCS データへ切り換わるたびに、 データの長さにそれぞれ 2 バイトを追加してください。 さらに可搬性を良くするためには、 混合データを使用するアプリケーションには可変長ストリングを使用してください。
長フィールド (長さが 254 文字を超えるストリング) は、システムによって扱い方が異なります。 ホストまたは AS/400 サーバーは、 長フィールド用のスカラー関数のサブセットだけをサポートしています。 たとえば、DB2 ユニバーサル・データベース (OS/390 版) では、 長フィールドに合わせて LENGTH および SUBSTR 関数だけが許されます。 また、ホストまたは AS/400 サーバーでは、 ある種の SQL ステートメントには別の取り扱いが必要になります。 たとえば DB2 (VSE および VM 版) では、INSERT ステートメントを用いる場合、ホスト変数、 SQLDA、またはヌル値だけを使用することが必要です。
LOB データ・タイプは DB2 コネクトでサポートされています。
DB2 コネクトではユーザー定義の具象タイプだけがサポートされています。 抽象データ・タイプはサポートされていません。
ROWID データ・タイプは、DB2 コネクトではビット・データ用の VARCHAR として処理されます。
DB2 コネクトでは 8 バイト (64 ビット) 整数がサポートされています。 BIGINT 整数データ・タイプは、データ精度を保ちながら大規模データベースのカー ディナリティーをサポートするときに使用します。
各 IBM 関係データベース管理システムでは、 GRANT および REVOKE SQL ステートメントにいろいろなレベルの区分が用意されています。 各データベース管理システムで使用するのに適した SQL ステートメントを確認するために、 製品特定の出版物を調べてください。
DB2 は、パラメーターを指定していない CONNECT を、 CONNECT ステートメントの CONNECT TO および CONNECT RESET バージョンと同様にサポートしています。 アプリケーションが CONNECT TO ステートメントを先に明示的に実行せずに SQL ステートメントを呼び出した場合、 省略時アプリケーション・サーバー (それが存在する場合) への暗黙 接続が実行されます。
データベースに接続するときには、 関係データベース管理システムを識別するための情報が SQLCA の SQLERRP フィールドに戻されます。 アプリケーション・サーバーが IBM 関係データベースの場合、 SQLERRP の先頭の 3 バイトは以下のいずれかを含みます。
DB2 コネクトを使用しているときに CONNECT TO または null CONNECT ステートメントを発行した場合、 SQLCA の SQLERRMC フィールド内には国別コードまたは領域トークンがブランクとして戻されます。 アプリケーション・サーバーの CCSID はコード・ページまたはコード・セット・トークンに戻されます。
明示的に切断を行うには、CONNECT RESET ステートメント (タイプ 1 接続の場合)、 RELEASE および COMMIT ステートメント (タイプ 2 接続の場合)、 または DISCONNECT ステートメント (どちらの接続タイプでも可、 ただし TP モニター環境では不可) を使用します。
接続が明示的に切断されずにアプリケーションが正常終了した場合、 DB2 コネクトは結果のデータを暗黙のうちにコミットします。
注: | アプリケーションが正常終了したのに、 エラーを示す SQLCODE を依然として受け取る場合があります。 この場合、DB2 コネクトはデータをコミットします。 データのコミットを行いたくない場合は、ROLLBACK コマンドを発行してください。 |
FORCE コマンドは、選択したユーザーまたはすべてのユーザーをデータベースから切断します。 これはホストまたは AS/400 サーバー・データベースにもサポートされるので、 ユーザーは DB2 コネクト・ワークステーションの強制切断を行うことができます。
各種の IBM 関係データベース・システムの間で、 プリコンパイルに関していくつかの相違点があります。 DB2 ユニバーサル・データベース用のプリコンパイラーは、 以下の点でホストまたは AS/400 サーバーのプリコンパイラーと異なります。
DB2 コネクトは、 DB2 データベース・マネージャーのブロック化バインド・オプションをサポートします。
DB2 コネクト・プログラムは、 DB2 データベース・マネージャー構成ファイルで定義された ブロック・サイズを RQRIOBLK フィールドに使用します。 DB2 コネクトの現行バージョンでは、 ブロック・サイズを最大 32 767 までサポートします。 それより大きな値が DB2 データベース・マネージャー構成ファイルで指定される場合、 DB2 コネクトは 32 767 値を使用しますが、 DB2 データベース・マネージャーをリセットしません。 ブロック化は、動的 SQL と静的 SQL で同じブロック・サイズが使用され、 同じ方法で処理されます。
注: | ほとんどのホストまたは AS/400 サーバー・システムは動的カーソルを未確定とみなしますが、 DB2 ユニバーサル・データベース・システムは一部の動的カーソルを確定カーソルとみなします。 混乱を避けるため、DB2 コネクトでは BLOCKING ALL を指定することができます。 |
管理 API 解説書 およびコマンド解説書 でリストしているように、CLP、コントロール・センター、 または API を使用して DB2 データベース・マネージャー構成ファイルにおいてブロック・サイズを指定してください。
パッケージには以下の属性があります。
それぞれのホストまたは AS/400 サーバー・システムで、これらの属性の使用に関する制限があります。
注: | DB2 コネクトは、 DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベースで SET CURRENT PACKAGESET コマンドをサポートしています。 |
CNULREQD バインド・オプションは、 LANGLEVEL オプションを使用して指定したヌル文字で終了するストリングの処理をオーバーライドします。
LANGLEVEL オプションを MIA または SAA1 に設定した場合にヌル文字で終了するストリングがどのように処理されるかについては、 アプリケーション開発の手引き を参照してください。
省略時には、CNULREQD は YES に設定されます。 こうすることによって、ヌル文字で終了するストリングは MIA 標準に従って解釈されます。 DB2 ユニバーサル・データベース (OS/390 版) サーバーに接続している場合には、CNULREQD を YES に設定するよう強くお勧めします。 CNULREQD オプションを NO に設定して、 (ヌル文字で終了するストリングに関係して) SAA1 標準にコード化されたアプリケーションをバインドする必要があります。 そうしなければ、ヌル文字で終了するストリングを SAA1 に設定した LANGLEVEL を使用して作成しても、 MIA 標準で解釈される場合があります。
ISO/ANS SQL92 で定義されているスタンドアロン SQLCODE および SQLSTATE 変数は、 LANGLEVEL SQL92E プリコンパイル・オプションを介してサポートされます。 SQL0020W 警告がプリコンパイル時刻に発行される場合は、 LANGLEVEL がサポートされていないことを示しています。 この警告は LANGLEVEL SQL92E のサブセットである コマンド解説書 で LANGLEVEL MIA の下にリストされている機能にのみ適用されます。
EBCDIC と ASCII の差は、種々のデータベース製品間の分類順序の差を引き起こし、 ORDER BY と GROUP BY 句にも影響を及ぼします。 それらの差を最小限にとどめる方法の 1 つは、 EBCDIC 分類順序に模倣するユーザー定義の照合順序を作成することです。 照合順序の指定は、新規データベースを作成するときだけ行うことができます。 詳細については、 アプリケーション開発の手引き、管理 API 解説書、 およびコマンド解説書 を参照してください。
注: | データベース表は ASCII 形式の DB2 ユニバーサル・データベース (OS/390 版) に保管できるようになりました。 このことは DB2 コネクトと DB2 ユニバーサル・データベース (OS/390 版) 間のより速いデータの交換を可能にします。また、これによりデータを変換 したり並べかえるのに使用するフィールド手順は必要なくなります。 |
システムが異なると参照制約の扱い方も異なります。
他の規則については、関係する連鎖のレベルにより変化します。
データベース・サーバーのロッキング方法は、アプリケーションにまで影響することがあります。 たとえば、行レベルのロックで設計されたアプリケーション、およびカーソル固定の分離レベルは、 ページ・レベルのロックを実行するシステムに直接移送することはできません。 これらの潜在的な差のゆえに、アプリケーションを調整する必要のある場合があります。
DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベース製品には、ロックをタイムアウトにして待機中のアプリケーションにエラー戻りコードを送る機能があります。
異なる IBM 関係データベース製品は、 類似のエラーについて必ずしも同じ SQLCODE を発行するものではありません。 この問題には、2 とおりの対処の仕方があります。
SQLSTATE は、どのデータベース製品でもほぼ同一の意味を持ち、 それらの製品は SQLCODE に対応する SQLSTATE を作成します。
省略時には、 DB2 コネクトは SQLCODE およびトークンを各 IBM ホストまた は AS/400 サーバー・システムからユーザーの DB2 ユニバーサル・データベースのシステムへマッピングします。省略時のマッピングを指定変更したい場合や、 SQLCODE マッピングのないデータベース・サーバー (非 IBM データベース・サーバー) を使用している場合には、 独自の SQLCODE マッピング・ファイルを指定することができます。 SQLCODE マッピングをオフにすることもできます。
詳細については、SQLCODE マッピングを参照してください。
システム・カタログは、IBM データベース製品により異なります。 視点を使用することにより、多くの相違点をマスクすることができます。 詳細については、使用しているデータベース・サーバーの資料を参照してください。
CLI にあるカタログ機能は、同じ API にサポートされることにより、この問題を克服し、 DB2 ファミリー全体のカタログ照会を設定していきます。
検索割り当てでのオーバーフローは、 IBM 関係データベース製品によって異なった処理がなされる場合があります。 たとえば、DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベースから整数のホスト変数の中に浮動列を取り入れることを考慮してください。 浮動値を整数値に変換する際に、変換オーバーフロー (桁あふれ) が生じる場合があります。 省略時解釈では DB2 ユニバーサル・データベース (OS/390 版) は、 アプリケーションに警告 SQLCODE およびヌル値を戻します。一方、DB2 ユニバーサル・データベースは変換オーバーフロー・エラーを戻します。適正なサイズのホスト変数を取り出すことにより、 検索割り当てにおける数値変換オーバーフローを回避するようお勧めします。
アプリケーションを prep またはバインドするとき、 DB2 コネクトは以下の分離レベルを受け入れます。
分離レベルは保護の大きい順にリストしてあります。 指定した分離レベルをホストまたは AS/400 サーバーがサポートしていない場合、 その次に高いサポートされているレベルが使用されます。
表 2 は、各ホストまたは AS/400 アプリケーション・サーバーにおけるそれぞれの分離レベルの結果を示しています。
DB2 コネクト | DB2 ユニバーサル・データベース (OS/390 版) | DB2 (VSE および VM 版) | DB2 ユニバーサル・データベース (AS/400 版) | DB2 ユニバーサル・データベース |
---|---|---|---|---|
RR | RR | RR | 注 1 | RR |
RS | 注 2 | RR | COMMIT(*ALL) | RS |
CS | CS | CS | COMMIT(*CS) | CS |
UR | 注 3 | CS | COMMIT(*CHG) | UR |
NC | 注 4 | 注 5 | COMMIT(*NONE) | UR |
注:
|
DB2 ユニバーサル・データベース (AS/400 版) では、分離レベルが UR でブロック化が ALL にセットされていてアプリケーションがバインドされているならば、 もしくは分離レベルが NC にセットされているならば、ジャーナルされていない表にアクセスすることができます。
クライアント・プログラムは SQL CALL ステートメントを発行することにより、 サーバー・プログラムを呼び出すことができます。 この場合、各サーバーの機能の仕方は他のサーバーと若干異なります。
REXX/SQL から DB2 (AS/400 版) に対する CALL ステートメントはすべて、 CALL USING DESCRIPTOR 形式の REXX/SQL マップで設定された CALL ステートメントとしてアプリケーションにより動的に作成され、 実行される必要があります。
SQL CALL ステートメントの構文については、 SQL 解説書 を参照してください。 アプリケーション・プログラムの作成の際のストアード・プロシージャーの使用法に関しては、 アプリケーション開発の手引き を参照してください。
DB2 ユニバーサル・データベース上のサーバー・プログラムは、DB2 ユニバーサル・データベース (OS/390 版) 、DB2 ユニバーサル・データベース (AS/400 版) 、 または DB2 (VSE および VM 版) で使用されるサーバー・プログラムと同じパラメーター規則を指定して起動できます。 DB2 ユニバーサル・データベースのストアード・プロシージャーを起動する方法について詳しくは、 アプリケーション開発の手引き を参照してください。 特定のプラットフォーム用のパラメーター規則に関する詳細は、 そのプラットフォームに関する DB2 製品資料を参照してください。
ストアード・プロシージャー内のすべての SQL ステートメントは、 クライアント SQL プログラムによって開始される SQL 作業単位の一部として実行されます。
DB2 ユニバーサル・データベース相互間では、ユーザーが標識変数に何を入力しても、システムはすべて渡します。 ただし、DB2 コネクトを使用する場合、 標識変数のうち 0、-1、および -128 だけを渡すことができます。
DB2 ユニバーサル・データベース上のサーバー・プログラムは、 SQLCA を更新してエラーや警告をすべて返すことができますが、 DB2 ユニバーサル・データベース (OS/390 版) または DB2 ユニバーサル・データベース (AS/400 版) 上のストアード・プロシージャーにはそのような機能はありません。 ユーザーのストアード・プロシージャーからエラー・コードを返したい場合には、 パラメーターとして渡す必要があります。 SQLCODE および SQLCA は、システム検出エラー用にサーバーだけが設定します。
DB2 ストアード・プロシージャー・ビルダーは、ストアード・プロシージャーの作成、インストール、 テストのための使いやすい開発環境です。 これを使うことで、DB2 サーバー上におけるストアード・プロシージャーの登録、 構築、インストールといった細かい作業に注意を奪われることなく、 ストアード・プロシージャーのロジックを作成することに集中できます。 さらに、ストアード・プロシージャー・ビルダーを使えば、 あるオペレーティング・システム上でストアード・プロシージャーを開発し、 別のサーバー・オペレーティング・システム上でそれらを構築することも可能になります。
ストアード・プロシージャー・ビルダーはグラフィカルなアプリケーションであり、 迅速な開発をサポートしています。 ストアード・プロシージャー・ビルダーを使えば、以下の作業を行うことができます。
ストアード・プロシージャー・ビルダーは「DB2 ユニバーサル・データベース (DB2 Universal Database)」プログラム・グループから単独のアプリケーションとして起動できます。 あるいは、以下のいずれかの開発用アプリケーションから起動することも可能です。
さらに、DB2 (OS/390 版) のコントロール・センターからストアード・プロシージャー・ビルダーを起動することもできます。 ストアード・プロシージャー・ビルダーは単独のプロセスとして、 コントロール・センターの「ツール (Tools)」メニュー、ツールバー、 「ストアード・プロシージャー (Stored Procedure)」フォルダーなどから開始することが可能です。 また、「ストアード・プロシージャー・ビルダー・プロジェクト (Stored Procedure Builder Project)」ウィンドウからは、 DB2 (OS/390 版) サーバーに組み込まれた SQL ストアード・プロシージャーを 1 つ以上選択して、 コマンド行プロセッサー (CLP) 内で実行できる指定されたファイルへエクスポートできます。
ストアード・プロシージャー・ビルダーは作業結果を管理するのにプロジェクトを使用します。 それぞれのストアード・プロシージャー・ビルダー・プロジェクトには、 特定のデータベース (DB2 (OS/390 版) サーバーなど) への接続が保管されます。 また、フィルターを作成して各データベースごとにストアード・プロシージャーのサブセットを表示させることも可能です。 新規の、あるいは既存のストアード・プロシージャー・ビルダー・プロジェクトをオープンするときに、 ストアード・プロシージャーが名前、スキーマ、 言語、集合 ID (OS/390 のみ) に基づいて表示されるよう、 ストアード・プロシージャーにフィルターをかけることができます。
接続情報はストアード・プロシージャー・ビルダー・プロジェクトに保管されます。 そのため既存のプロジェクトをオープンすると、そのデータベースのユーザー ID とパスワードを入力するよう自動的に要求されます。 「SQL ストアード・プロシージャーの挿入 (Inserting SQL Stored Procedure)」ウィザードを使用すれば、 SQL ストアード・プロシージャーを DB2 (OS/390 版) サーバー上で構築できます。 DB2 (OS/390 版) サーバーに組み込まれた SQL ストアード・プロシージャーの場合、 コンパイル、プリリンク、リンク、バインド、 実行時、WLM 環境、外部セキュリティーといったオプションを具体的に設定できます。
さらに、その SQL ストアード・プロシージャーに関する SQL コスト情報を入手することもできます。 これには、その SQL ストアード・プロシージャーを実行しているスレッドの CPU 時間に関する情報やその他の DB2 コスト情報も含まれます。 特に、ラッチ / ロック競合の待ち時間、getpage の数、読み取り入出力の回数、 書き込み入出力の回数などに関するコスト情報を入手できます。
コスト情報を入手するにあたって、 ストアード・プロシージャー・ビルダーは DB2 (OS/390 版) サーバーに接続し、 SQL ステートメントを実行し、ストアード・プロシージャーを呼び出す (DSNWSPM) ことにより、 その SQL ストアード・プロシージャーが使った CPU 時間の量を調べます。
複合 SQL では、 複数の SQL ステートメントを単一の実行可能ブロックとしてグループにまとめることができます。 このようにすればネットワーク・オーバーヘッドを減らすことができ、応答時間が改善されます。
DB2 コネクトは NOT ATOMIC 複合 SQL をサポートしています。 このことは、複合 SQL の処理はエラーが生じた後にも続けられることを意味します。 (DB2 コネクトではサポートされていない ATOMIC 複合 SQL を使用した場合、 エラーが生じたときにはその複合 SQL グループ全体がロールバックされます。)
ステートメントは、 アプリケーション・サーバーによって終了させられるまで実行し続けます。 一般的に言って、 複合 SQL ステートメントの実行が停止するのは重大エラーが発生した場合だけです。
NOT ATOMIC 複合 SQL は、サポートされているホストまたは AS/400 アプリケーション・サーバーすべてで使用することができます。
複数の SQL エラーが発生した場合、 最初から 7 番目までの失敗したステートメントの SQLSTATE が、 SQLCA の SQLERRMC フィールドに戻されます。 その際、複数のエラーが発生したことを示すメッセージも一緒に戻されます。 詳細については、SQL 解説書 を参照してください。
DB2 コネクトを使って、複数サイト更新 (2 フェーズ・コミットともいう) を実行することができます。 複数サイト更新とは、 単一の分散作業単位 (DUOW) 内で複数のデータベースを更新することです。 ユーザーがこの機能を使用するかどうかはいくつかの要因によって決まります。
このサポートはネイティブの DB2 UDB アプリケーション、 および外部のトランザクション処理 (TP) モニター (IBM TXSeries、CICS for Open Systems、 BEA Tuxedo、Encina Monitor、および Microsoft Transaction Server など) に適用されます。
注: | BEA Tuxedo について詳しくは、DB2 コネクトをトランザクション処理モニターと組み合わせて使うを参照してください。
XA コンセントレーターについて詳しくは、 DB2 コネクトの接続コンセントレーターを参照してください。 |
TCP/IP 接続でホスト・データにアクセスするのにネイティブ DB2 アプリケーションと TP モニター・アプリケーションの両方が共通 DB2 コネクト エンタープライズ・エディション サーバーを使用しているなら、 同期点管理プログラムは必ず使用しなければなりません。
1 つの DB2 コネクト エンタープライズ・エディション サーバーから SNA と TCP/IP ネットワーク・プロトコルの両方を使ってホスト・データにアクセスし、 2 フェーズ・コミットが必要な場合は、同期点管理プログラムを使用しなければなりません。 このことは DB2 アプリケーションと TP モニター・アプリケーションの両方に当てはまります。
以下に挙げるステートメントは、ホストまたは AS/400 サーバーでの処理用に正常にコンパイルできますが、 DB2 ユニバーサル・データベース・システムでの処理用には正常にコンパイルできません。
上記のステートメントは、コマンド行プロセッサーでもサポートされています。
以下に挙げるステートメントは、ホストまたは AS/400 サーバーでの処理用にサポートされていますが、 バインド・ファイルやパッケージに付加されることはなく、コマンド行プロセッサーによるサポートもありません。
プリコンパイラーは以下のことを仮定します。
以下の SQL ステートメントは、DB2 コネクトでもコマンド行プロセッサーでもサポートされていません。
DB2 (VSE および VM 版) により拡張された動的 SQL ステートメントは、 -104 および構文エラー SQLCODE で拒否されます。