コネクティビティー 補足

アプリケーション・サーバーのセットアップ

DB2 (MVS/ESA 版) のアプリケーション・サーバー・サポートによって、 DB2 (MVS/ESA 版) は DRDA アプリケーション・リクエスターのサーバーとして機能することができます。 DB2 (MVS/ESA 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターは、以下のものとして機能することができます。

DB2 (MVS/ESA 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターの場合、 DB2 (MVS/ESA 版) アプリケーション・サーバーは以下のようにデータベース・アクセスをサポートします。

ネットワーク情報の提供

DB2 (MVS/ESA 版) アプリケーション・サーバーが適正に分散データベース要求を処理するためには、次のステップを踏む必要があります。

  1. アプリケーション・サーバーをローカルのコミュニケーション・マネージャーに定義する。
  2. 使用される可能性のある各 2 次サーバーの宛先を定義し、 DB2 (MVS/ESA 版) アプリケーション・サーバーが SQL 要求を最終的な宛先に再経路指定できるようにする。
  3. 必要な機密保護を提供する。
  4. データ表示を提供する。

アプリケーション・サーバーを定義する

アプリケーション・サーバーが分散データベース要求を受信するためには、これをローカルなコミュニケーション・マネージャーに定義し、固有の RDB_NAME 名を割り当てる必要があります。アプリケーション・サーバーを正しく定義するには、次のステップを踏む必要があります。

  1. DB2 (MVS/ESA 版) アプリケーション・サーバーが使用する LU 名と RDB_NAME を選択する。これらの名前を DB2 (MVS/ESA 版) と VTAM に記録するプロセスは、 ローカル・システムの定義に説明されているプロセスと同じです。 DB2 (MVS/ESA 版) のために選択する RDB_NAME を、アプリケーション・サーバーへのコネクティビティーが必要なすべてのエンド・ユーザーおよびアプリケーション・リクエスターに供給しなければなりません。
  2. アクセスの必要なアプリケーション・リクエスターごとに NETID.LUNAME 値を DB2 (MVS/ESA 版) アプリケーション・サーバーに登録して、アプリケーション・リクエスターが SNA 要求を DB2 (MVS/ESA 版) サーバーに経路指定できるようにします。アプリケーション・リクエスターがダイナミック・ネットワーク・ルーティングを実行できる場合でも、そのようにしてください。アプリケーション・リクエスターは NETID.LUNAME を知らないとダイナミック・ネットワーク・ルーティングを使用できないからです。
  3. DRDA 省略時 TPN (X'07F6C4C2') を各アプリケーション・リクエスターに指定します。 DB2 (MVS/ESA 版) が自動的にこの値を使用するためです。
  4. アプリケーション・リクエスターで要求された各モード名ごとに、VTAM モード表に項目を作成します。これらの項目は、各モード名の RU サイズ、歩調合わせウィンドウ・サイズ、およびサービス・クラスを記述します。
  5. DB2 (MVS/ESA 版) アプリケーション・サーバーに接続するアプリケーション・リクエスターに、セッション限度を定義します。 VTAM APPL ステートメントは、すべてのパートナー・システムにあてはまる省略時のセッション限度を定義します。特定のパートナーに対して固有の省略時値を設定したい場合は、通信データベース (CDB) の SYSIBM.SYSLUMODES 表を使用できます。

    VTAM ネットワークを調べる方法については、 RU サイズおよび歩調合わせの設定を参照してください。

  6. DB2 (MVS/ESA 版) アプリケーション・サーバーへの接続が許可されたアプリケーション・リクエスターを識別するための項目を DB2 (MVS/ESA 版) CDB に作成します。ネットワーク内のアプリケーション・リクエスター用に CDB 項目を定義する 2 つの基本的な方法は、以下のとおりです。

    1. CDB で特に記述されていない、任意の LU に使用する省略時値を指定する行を SYSIBM.SYSLUNAMES に挿入できます (省略時の行は LUNAME 列がブランクです)。この方法では、ネットワーク内のいくつかの LU に対しては特定の属性を与え、一方、他のすべての LU については省略時値を設定できます。

      たとえば、DALLAS システム (別の DB2 (MVS/ESA 版) システム) には検査済み分散データベース要求 (LU 6.2 SECURITY=SAME) を送信することを許可する一方で、データベース・マネージャー・システムにはパスワードを送信させるということができます。さらに、特にデータベース・マネージャー・システムが多数ある場合などは、システムごとに CDB に項目を作成したくない場合もあります。 図 10 では、DALLAS システムに対して SECURITY=SAME を指定する一方、他のすべてのリクエスターに対しては SECURITY=PGM にさせるために CDB を使用する方法を示します。

      図 10. アプリケーション・リクエスター接続の省略時値の確立

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES (' ', ' ', 'C', 'N', 'N', ' ');
      

    2. CDB を次のいずれかに設定することにより、 CDB を使用してネットワーク内の各アプリケーション・リクエスターに個別に許可を与えることができます。
      • SYSIBM.SYSLUNAMES 中に省略時の行を記録しないようにする。省略時の行 (LU 名がブランクの行) が存在しない場合、DB2 (MVS/ESA 版) は、接続しようとする各アプリケーション・リクエスターの LU 名を含んだ SYSIBM.SYSLUNAMES 中の行を必要とします。対応する行が CDB に見つからない場合、アプリケーション・リクエスターはアクセスを拒否されます。
      • SYSIBM.SYSLUNAMES に、 come-from 検査が必要であることを指定した省略時の行を記録する (USERNAMES 列を 'I' または 'B' に設定)。これにより、Come-From 検査で説明されているように、 DB2 (MVS/ESA 版) はアクセスをアプリケーション・リクエスターおよび SYSIBM.SYSUSERNAMES 表で定義されたエンド・ユーザーに限定します。名前変換規則が SYSIBM.SYSLUNAMES 中にブランク LU 名の行を必要とするものの、この行の使用によって DB2 (MVS/ESA 版) が DB2 (MVS/ESA 版) アプリケーション・サーバーへの無制限なアクセスを許可するようにはしたくない場合、この方法を使用できます。

      図 11 では、LUNAME 列にブランクの行はないため、 DB2 (MVS/ESA 版) は LUDALLAS または LUNYC 以外の LU へのアクセスをすべて拒否します。

      図 11. 個々のアプリケーション・リクエスター接続の識別

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
      

2 次サーバーの定義

DB2 (MVS/ESA 版) では、DRDA に定義したデータベース・サーバーを実装していません。その代わり、DB2 (MVS/ESA 版) では 2 次サーバーを使用できます。これは、システム主導アクセスを使って単一の作業単位の範囲で複数の DB2 (MVS/ESA 版) システムにアクセスすることを可能にします。

SQL の相違

システム主導アクセスで主導サポートされる SQL は、 DRDA リモート作業単位の場合と大いに異なります。

SQL オブジェクト名

DB2 (MVS/ESA 版) アプリケーション・サーバーは、SQL 要求を受け取るとオブジェクト名を調べて、オブジェクトがネットワークのどこに位置しているかを判別します。 DB2 (MVS/ESA 版) は、1 つの部分からなる SQL オブジェクト名、 2 つの部分からなる SQL オブジェクト名、 3 つの部分からなる SQL オブジェクト名のいずれも受け入れます。それぞれ名前の形式は次のようになります。

objectname DB2 (MVS/ESA 版) の表、視点、シノニム、別名の名前を指定します。

authid.objectname オブジェクトの所有者とオブジェクト名を指定します。

location.authid.objectname 所有者のシステム、所有ユーザー、およびオブジェクトの名前を指定します。

ロケーション名 (3 つの部分からなるオブジェクト名の最初の部分) がローカルな DB2 (MVS/ESA 版) システムの RDB_NAME と一致する場合、要求はローカルな DB2 (MVS/ESA 版) オブジェクトを識別します。

ロケーション名がローカルな DB2 (MVS/ESA 版) システムの RDB_NAME と一致しない場合、 DB2 (MVS/ESA 版) アプリケーション・サーバーは、システム主導アクセスを使用して、ロケーション名によって識別されるシステムに要求を再経路指定します。システム主導アクセスは DB2 (MVS/ESA 版) システム間でのみサポートされるため、ターゲット・システムは別の DB2 (MVS/ESA 版) システムでなければなりません。システム主導アクセスはリモート・バインド機能をサポートしないため、アプリケーションを実行前にサーバーでバインドする必要はありません。 図 12 は、 DB2 (MVS/ESA 版) が SQL オブジェクト名を解決するのに使用するプロセスを要約しています。

図 12. DB2 (MVS/ESA 版) SQL オブジェクト名の解決


REQTEXT

サーバー定義

DB2 (MVS/ESA 版) アプリケーション・サーバーが SQL を再経路指定する場合、 CDB および VTAM に各 2 次サーバーを定義する必要があります。定義のプロセスは、リモート・システムの定義に説明されているプロセスとよく似ています。 2 次サーバーを接続するには、次の手順に従ってください。

  1. 各サーバーの RDB_NAME と LU 名値を CDB および VTAM に記録する。システム主導アクセスで使用される TPN 値は、DRDA の省略時値と異なります。しかし、DB2 (MVS/ESA 版) は自動的に正しい値を選択するので、この相違は重要ではありません。
  2. 2 次サーバーごとに機密保護要件を SYSIBM.SYSLUNAMES に定義する。このプロセスについては、機密保護の提供に説明されています。
  3. DB2 (MVS/ESA 版) アプリケーション・サーバーと 2 次サーバーの間で使用されるモード名 (複数の場合もある) を定義し、これらのモード名を VTAM モード表に入れる。省略時解釈モード名は IBMDB2LM です。
  4. 各 2 次サーバーのセッション限度を定義する。セッション限度を確立するためのプロセスは、 ローカル・システムの定義に説明されているプロセスと同じです。しかし、システム主導アクセスの場合、SQL アプリケーションごとに複数の会話を確立できます。システム主導アクセス接続の場合は、 DRDA 接続の場合に比べてセッション限度を高く設定する必要があるかもしれません。 システム主導アクセス・アプリケーションに必要な LU 6.2 セッションの数を計算する方法の詳細については、 DB2 管理の手引き の『分散データベース』を参照してください。

データベース資源の所有者として、 2 次サーバーはそこにある SQL オブジェクトのデータベース機密保護を制御します。ただしこの責任は、要求を出す DB2 (MVS/ESA 版) アプリケーション・サーバーと共有されます。サーバーは SQL オブジェクトに対するアクセスを次のように制御します。

機密保護の提供

アプリケーション・リクエスターが分散データベース要求を DB2 (MVS/ESA 版) アプリケーション・サーバーに向けるときには、以下の機密保護上の考慮事項が関係します。

Come-From 検査

DB2 (MVS/ESA 版) アプリケーション・サーバーがエンド・ユーザー名をアプリケーション・リクエスターから受け取る場合、アプリケーション・サーバーは指定されたアプリケーション・リクエスターから受け取るエンド・ユーザー名を制限できます。これは come-from 検査を使用することで行えます。 come-from 検査を使用すると、アプリケーション・サーバーは、所定のユーザー ID が特定のパートナーだけに使用されるよう指定できます。たとえば、アプリケーション・サーバーは JONES を DALLAS だけ「から来る (come-from)」よう制限できます。 (DALLAS 以外の) 別のアプリケーション・リクエスターが名前 JONES をアプリケーション・サーバーに送ろうとする場合、アプリケーション・サーバーはその名前が適正なネットワーク・ロケーションから来なかったために要求を拒否できます。

DB2 (MVS/ESA 版) は come-from 検査をインバウンド・エンド・ユーザー名前変換の一部として実装しています。これについては次の節で説明します。

エンド・ユーザー名の選択

アプリケーション・リクエスターによって渡されるユーザー ID は、 SNA ネットワーク全体で一意ではないことがあります。 DB2 (MVS/ESA 版) アプリケーション・サーバーはインバウンド名前変換を実行して、 SNA ネットワーク全体を通じて固有なエンド・ユーザー名を作成する必要があるかもしれません。同様に、DB2 (MVS/ESA 版) アプリケーション・サーバーはアウトバウンド名前変換を実行して、アプリケーションに関係する 2 次サーバーに対して固有なエンド・ユーザー名を与える必要があるかもしれません。 (アウトバウンド・エンド・ユーザー名前変換については、 機密保護の提供を参照してください。)

インバウンド名前変換は、 SYSIBM.SYSLUNAMES 表の USERNAMES 列を 'I' (インバウンド変換) または 'B' (インバウンドおよびアウトバウンド両方の変換) に設定することにより、使用可能にできます。インバウンド名前変換が有効であるとき、 DB2 (MVS/ESA 版) はアプリケーション・リクエスターによって送られたユーザー ID を変換して、 DB2 (MVS/ESA 版) は所有者の名前を立案します (アプリケーション・リクエスターが別の DB2 (MVS/ESA 版) システムである場合)。

アプリケーション・リクエスターがユーザー ID およびパスワードの両方を APPC ALLOCATE verb に関して送る場合、ユーザー ID およびパスワードはユーザー ID が変換される前に妥当性検査されます。 SYSIBM.SYSUSERNAMES の PASSWORD 列は、パスワード妥当性検査には使用されません。代わりに、ユーザー ID とパスワードが妥当性検査のため、外部機密保護システム (RACF または RACF と同等の製品) に送られます。

ALLOCATE verb の着信ユーザー ID が検査されるとき、 DB2 (MVS/ESA 版) は許可出口ルーチンを持ちます。これは、2 次 AUTHID のリストを提供し、追加の機密保護検査を実行するために使用できます。詳細については、 DB2 管理の手引き を参照してください。

インバウンド名前変換処理は SYSIBM.SYSUSERNAMES 表の中の行を検索しますが、これは以下の優先順位リスト (TYPE.AUTHID.LUNAME) のうちのパターンの 1 つと一致しなければなりません。

  1. I.AUTHID.LUNAME − 特定のアプリケーション・リクエスターからの特定のエンド・ユーザー
  2. I.AUTHID.blank − 任意のアプリケーション・リクエスターからの特定のエンド・ユーザー
  3. I.blank.LUNAME − 特定のアプリケーション・リクエスターからの任意のエンド・ユーザー

行が検出されない場合、リモート・アクセスは拒否されます。行が検出されると、リモート・アクセスが許可され、エンド・ユーザー名は NEWAUTHID 列で与えられた値に変換されます。 NEWAUTHID 値がブランクの場合は名前が変更されないことを示します。任意の DB2 (MVS/ESA 版) 資源に対する許可の検査 (たとえば、SQL 表特権) が、DB2 (MVS/ESA 版) により、元のユーザー名ではなく変換されたエンド・ユーザー名に対して実行されます。

DB2 (MVS/ESA 版) アプリケーション・サーバーがアプリケーション・リクエスターからエンド・ユーザー名を受け取る場合、 DB2 (MVS/ESA 版) インバウンド名前変換機能を使用することによって以下のいくつかの目的が達成されます。

ネットワーク機密保護の提供

LU 6.2 は、主に 3 つのネットワーク機密保護機能を提供します。

ネットワーク機密保護では、 DB2 (MVS/ESA 版) でのセッション・レベル機密保護および暗号化について説明しています。 DB2 (MVS/ESA 版) アプリケーション・サーバーは、DB2 (MVS/ESA 版) アプリケーション・リクエスターとまったく同様に、セッション・レベルの機密保護および暗号化を使用します。

残りのネットワーク機密保護の考慮事項は、SNA 会話レベル機密保護だけです。会話レベル機密保護のいくつかの面は DB2 (MVS/ESA 版) アプリケーション・サーバー独自のものです。 DB2 (MVS/ESA 版) アプリケーション・サーバーはネットワーク機密保護において 2 つの異なった役割を果たします。

機密保護違反が検出された場合、 LU 6.2 は DB2 (MVS/ESA 版) アプリケーション・サーバーが SNA 機密保護違反センス・コード ('080F6051'X) をアプリケーション・リクエスターに送るようにします。このセンス・コードは障害の原因を示すものではないので、 DB2 (MVS/ESA 版) は 2 つの方式で分散機密保護違反の原因を記録します。

データベース・マネージャー機密保護

データベース資源の所有者として、DB2 (MVS/ESA 版) アプリケーション・サーバーは、そこにある SQL オブジェクトに対してデータベース機密保護機能を制御します。 DB2 (MVS/ESA 版) が管理するオブジェクトへのアクセスは、特権によって制御されます。これは、DB2 (MVS/ESA 版) 管理者または個々のオブジェクトの所有者によって、ユーザーに与えられます。 DB2 (MVS/ESA 版) アプリケーション・サーバーが制御する 2 つの基本的なオブジェクトのクラスは以下のとおりです。

パッケージを作成するとき、 DISABLE/ENABLE オプションによって、どの DB2 (MVS/ESA 版) 接続タイプがパッケージを実行できるか制御することができます。 RACF および DB2 (MVS/ESA 版) 機密保護出口ルーチンを使用して、エンド・ユーザーに選択的に DDF の使用を許可できます。 RLF を使用して、リモート・バインドおよび動的 SQL 実行のプロセッサー時間を制限できます。

MYPKG という名前の DB2 (MVS/ESA 版) パッケージについて考慮します。これは JOE が所有しているものとします。 JOE は SAL に対して、 DB2 (MVS/ESA 版) GRANT USE ステートメントを発行することにより、このパッケージの実行を許可できます。 SAL がこのパッケージを実行すると、以下の事柄が発生します。

機密保護サブシステム

DB2 (MVS/ESA 版) アプリケーション・サーバーの機密保護サブシステム (RACF または RACF と同等の製品) の使用法は、 SYSIBM.SYSLUNAMES 表でインバウンド名前変換機能をどのように定義したかに応じて異なります。

データの表示

ご使用の DB2 (MVS/ESA 版) サブシステムが、各アプリケーション・リクエスターの CCSID を DB2 (MVS/ESA 版) サブシステムのインストール・システムの CCSID に変換できるかどうか確認する必要があります。詳細については、データの表示を参照してください。


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