コネクティビティー 補足

DB2 ユニバーサル・データベース (OS/390 版) インプリメンテーション

DRDA は、分散データベース管理システム機能のタイプを定義します。 DB2 ユニバーサル・データベース (OS/390 版) はリモート作業単位をサポートしています。リモート作業単位を使用すると、あるシステムで実行されているアプリケーション・プログラムは、 1 つのリモート DBMS のデータにアクセスできます。そのときにはそのリモート DBMS が提供する SQL を使用します。

DB2 ユニバーサル・データベース (OS/390 版) は、分散作業単位もサポートしています。分散作業単位を使用すると、あるシステムで実行されているアプリケーション・プログラムは、複数のリモート DBMS のデータにアクセスできます。そのときには各リモート DBMS が提供する SQL を使用します。 DRDA で定義される分散のタイプの詳細については、分散関係データベース体系 接続の手引き を参照してください。

図 14 に示されているとおり、 DB2 ユニバーサル・データベース (OS/390 版) は 2 種類のアクセス方式を使用して、 3 種類の分散データベース接続構成をサポートしています。

[1] システム主導アクセス (DB2 ユニバーサル・データベース (OS/390 版) プライベート・プロトコル を使用するアクセスとしても知られている) により、 DB2 ユニバーサル・データベース (OS/390 版) リクエスターは 1 つ以上の DB2 ユニバーサル・データベース (OS/390 版) サーバーに接続することができます。 DB2 ユニバーサル・データベース (OS/390 版) リクエスターとサーバーとの間に確立される接続は、 DRDA で定義されたプロトコルに適合しないため、非 DB2 ユニバーサル・データベース (OS/390 版) 製品を DB2 ユニバーサル・データベース (OS/390 版) に接続するのには使用できません。このタイプの接続は、 3 つの部分からなる名前または別名をアプリケーションにコーディングすることによって確立されます。

[2] アプリケーション主導アクセス では、 DB2 ユニバーサル・データベース (OS/390 版) リクエスターまたは非 DB2 ユニバーサル・データベース (OS/390 版) リクエスター (DB2 コネクトなど) を、 1 つ以上の DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーまたは非 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバー、たとえば DB2 ユニバーサル・データベースや DB2 ユニバーサル・データベース (AS/400 版) などに接続できます。アプリケーション・リクエスターに一度に接続できるアプリケーション・サーバーの数は、アプリケーション・リクエスターの DB2 ユニバーサル・データベース (OS/390 版) のレベルに応じて異なります。アプリケーション・リクエスターが DB2 (MVS/ESA 版) V2R3 であれば、一度に 1 つだけアプリケーション・サーバーを接続できます。このタイプの接続は、 SQL CONNECT ステートメントをアプリケーションにコーディングすることによって確立されます。アプリケーション・リクエスターが DB2 (MVS/ESA 版) V3R1 以降であれば、一度に 1 つ以上のアプリケーション・サーバーを接続できます。

[3] アプリケーション主導およびシステム主導アクセスを一緒に使用して接続を確立できます。 DRDA とシステム主導記憶域を同一のスレッドの中で使用して接続することはできません。

2 次サーバー という用語は、アプリケーション・サーバーのサーバーとして機能するシステムを指して用いられます。

構成の中に含まれるすべてのシステムが 2 フェーズ・コミットをサポートしている場合、分散作業単位 (複数サイト読み取りと複数サイト更新) がサポートされます。すべてのシステムが 2 フェーズ・コミットをサポートしているわけではない場合、作業単位内での更新は、2 フェーズ・コミットをサポートしない単一のサイト、または 2 フェーズ・コミットをサポートするサイトのサブセットのいずれかに制限されます。

図 14. DB2 ユニバーサル・データベース (OS/390 版) 分散接続


REQTEXT

表 2 は、DB2 ユニバーサル・データベース (OS/390 版) 分散データベースの接続タイプを比較したものです。

表 2. DB2 ユニバーサル・データベース (OS/390 版) 分散データベースの接続の比較
[1] システム主導アクセス [2] アプリケーション主導アクセス (すべてのシステムが 2 フェーズ・コミットをサポートする場合) [3] アプリケーション主導およびシステム主導アクセス
すべてのパートナーが DB2 ユニバーサル・データベース (OS/390 版) システムでなければならない。 任意の 2 つの DRDA システムを相互接続できる。 アプリケーション・リクエスターは任意の DRDA システムでかまわないが、サーバーは DB2 ユニバーサル・データベース (OS/390 版) システムでなければならない。
複数のパートナーに直接接続できる。 複数のパートナーに直接接続できる。 アプリケーション・リクエスターは直接アプリケーション・サーバーに接続できる。アプリケーション・サーバーは複数の DB2 ユニバーサル・データベース (OS/390 版) 2 次サーバーに接続できる。
各 SQL アプリケーションは、各サーバーと複数の会話を行うことができる。 各 SQL アプリケーションは各サーバーと 1 つの会話ができる。 SQL アプリケーションは、各サーバーと 1 つの会話を行うことができる。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーションは、アプリケーションの各サーバーと複数の会話を確立できる。
1 コミットの範囲内でローカル資源とリモート資源の両方にアクセスできる。 1 コミットの範囲内でローカル資源とリモート資源の両方にアクセスできる。 アプリケーション・リクエスターとアプリケーション・サーバーはローカル・データとリモート・データにアクセスできる。
大規模な照会、および複数の照会を同時に行う場合に効果的。 1 コミットの範囲内で実行回数がわずかな SQL ステートメントの場合に効果的。 アプリケーション・リクエスターとアプリケーション・サーバー間の接続は [2] と同様に動作し、 2 次サーバー接続は [1] と同様に動作する。
静的または動的 SQL をサポートできるが、コミットの範囲内で最初に静的 SQL を実行するとき、サーバーは静的 SQL を動的にバインドする。 静的または動的 SQL を発行できる。 アプリケーション・リクエスターとアプリケーション・サーバーは静的または動的 SQL を発行できる。 2 次サーバーは静的または動的 SQL をサポートしているが、コミットの範囲内で最初に静的 SQL を実行するとき、静的 SQL を動的にバインドする。
SQL INSERT、DELETE、 UPDATE ステートメント、および SELECT をサポートするステートメントに制限されている。 システムがサポートしているステートメントであれば、どれでも使用できる。 アプリケーション・サーバーはすべての SQL をサポートしている。 2 次サーバーは DML SQL だけをサポートしている (CREATE または ALTER など)。

追加機密保護拡張

拡張機密保護コード

DB2 ユニバーサル・データベース for OS/390 バージョン 5.1 よりも前のバージョンでは、ユーザー ID またはパスワードを指定した接続要求が失敗した場合、 SQL30082 理由コード 0 が返されるものの、問題となっている点に関して他の指示は出されませんでした。

DB2 ユニバーサル・データベース for OS/390 バージョン 5.1 は機能が拡張され、拡張機密保護コードをサポートするようになりました。拡張機密保護を指定すると、理由コードのほかに (PASSWORD EXPIRED) などの診断が追加されます。

これを活用するには、 DB2 ユニバーサル・データベース (OS/390 版) の拡張機密保護用に ZPARM インストール・パラメーターの値を YES に設定する必要があります。 EXTSEC=YES に設定するには、DB2 ユニバーサル・データベース (OS/390 版) のインストール・パネル DSN6SYSP を使用します。これを設定するために、DDF パネル 1 (DSNTIPR) を使用することもできます。省略時値は EXTSEC=NO です。パスワードの有効期限が切れた場合、PC、UNIX、Apple Macintosh、および DB2 コネクトを使用している Web アプリケーションはエラー・メッセージ SQL01404 を受け取ります。

検査済みの TCP/IP 機密保護

DB2 ユニバーサル・データベースの機密保護オプション AUTHENTICATION=CLIENT をサポートさせたい場合、 DB2 ユニバーサル・データベース (OS/390 版) のインストール・パネル DSNTIP4 (DDF パネル 2) を使用して、検査済みの TCP/IP 機密保護を YES に設定します。

デスクトップ ODBC および Java アプリケーションの機密保護

ワークステーション ODBC および Java アプリケーションは動的 SQL を使用します。この動的 SQL はインストールの際に機密保護上の問題の原因となることがあります。 DB2 ユニバーサル・データベース (OS/390 版) は、所有者とバインダーの両方の権限で動的 SQL を実行できる、新しいバインド・オプション DYNAMICRULES(BIND) を導入しています。 DYNAMICRULES を DB2 コネクトを介して指定する方法については、 コマンド解説書 を参照してください。

DB2 ユニバーサル・データベースおよび DB2 コネクトには、 DB2CLI.INI 構成ファイル内に新しい CLI/ODBC 構成パラメーター CURRENTPACKAGESET があります。これは適切な特権を持つスキーマ名に設定することが必要です。 SQL SET CURRENT PACKAGESET schema ステートメントは、アプリケーションの各接続ごとに自動的に出されます。

DB2CLI.INI を更新するためには、ODBC マネージャーを使用します。詳しくは、インストールおよび構成 補足 を参照してください。

パスワード変更サポート

SQL CONNECT ステートメントがユーザー ID のパスワードの有効期限が切れていることを示すメッセージを戻す場合、 DB2 コネクトのバージョン 5.2 以降では TSO にサインオンしなくてもパスワードを変更できるようになっています。 DRDA から、DB2 ユニバーサル・データベース (OS/390 版) はパスワードを変更できます。

旧パスワードと新規パスワード、および確認用パスワードを入力する必要があります。 DB2 コネクト エンタープライズ・エディションのサーバーで指定された機密保護が DCS である場合、パスワード変更の要求は DB2 ユニバーサル・データベース (OS/390 版) データベース・サーバーに送られます。指定した機密保護が SERVER である場合、 DB2 コネクト・サーバーのパスワードは変更されます。

他の利点は、LU を別々に定義する必要がないということです。追加情報は、DB2 コネクト エンタープライズ・エディションの概説およびインストール の資料を参照してください。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]