コネクティビティー 補足

VM 環境でのアプリケーション・サーバーのセットアップ

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

DB2 (VM 版) アプリケーション・サーバーに接続しているアプリケーション・リクエスターでは、 DB2 (VM 版) アプリケーション・サーバーによって、 DB2 (VM 版) アプリケーション・サーバーにローカルで保管されているデータベース・オブジェクト (表など) にアクセスできます。アプリケーション・リクエスターは、接続が確立される前に、アプリケーションの SQL ステートメントが含まれるパッケージを、 DB2 (VM 版) アプリケーション・サーバーに作成しなければなりません。

DB2 (VM 版) アプリケーション・サーバーが分散データベース要求を処理するためには、以下のステップを行ってください。

  1. アプリケーション・サーバーをローカル通信サブシステムに定義する。
  2. 必要な機密保護を提供する。
  3. データ表示を提供する。

ネットワーク情報の提供

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

アプリケーション・サーバーが分散データベース要求を受信するためには、アプリケーション・サーバーをローカル通信サブシステムに定義し、固有の RDB_NAME 名を割り当てます。

以下のステップを実行して、アプリケーション・サーバーを定義してください。

  1. DB2 (VM 版) アプリケーション・サーバーを SNA ネットワークに定義する。 DB2 (VM 版) アプリケーション・サーバーにゲートウェイ名および RDB_NAME を選択した後に、 ネットワーク情報の提供で説明されている手順に従ってください。 DB2 (VM 版) に対して選択する RDB_NAME は、 DB2 (VM 版) アプリケーション・サーバーへの接続が必要なすべてのユーザー (アプリケーション・リクエスター) に提供されていなければなりません。

    NETID は始動パラメーターとして VTAM に定義されており、アプリケーション・リクエスターからのすべての分散要求は正確にこのパラメーターに経路指定されます。 DB2 (VM 版) アプリケーション・サーバーは NETID を設定しません。

    DB2 (VM 版) アプリケーション・サーバーは、アプリケーション・リクエスターからのインバウンド分散要求を経路指定するゲートウェイを判別しません。アプリケーション・リクエスターが常にそれを制御します。 DB2 (VM 版) アプリケーション・リクエスターの場合、CMS 通信ディレクトリーが :luname および :tpn タグを使用してそれを指定します。

    DB2 (VM 版) アプリケーション・サーバーが分散作業単位活動をサポートするために、アプリケーション・リクエスターは、 SYNCLVL=SYNCPT パラメーターを使用して VTAM に定義されている AVS ゲートウェイを選択していなければなりません。必ず AVS ゲートウェイを定義して、分散作業単位をサポートするようにしてください。

  2. CRR 回復サーバーを作成します。これは、 VM システムで DB2 (VM 版) アプリケーション・サーバーの分散作業単位を管理するために使用されます。これを行うために、 VM/ESA 導入の手引き で説明されている IBM 提供のサーバーおよびファイルのインストール後のロードを行ってください。このステップには、 CRR サーバー (VMSERVR) および CRR ファイル・プール (VMSYSR) を定義することも含まれます。 CRR 回復サーバーを開始した時に、LUNAME を指定してください。これは SYNCLVL=SYNCPT が指定される AVS ゲートウェイの名前と同じです。
  3. アプリケーション・サーバー・マシンの CP ディレクトリーに IUCV *IDENT ステートメントがあることを確認してください。これは、サーバーをグローバル資源として識別します。
  4. アプリケーション・リクエスターが要求する各モード名ごとに、VTAM モード名表に項目を作成します。これらの項目には、特定のモード名のセッション特性 (RU サイズなど)、歩調合わせカウント、およびサービス・クラスを記述します。
  5. DB2 (VM 版) アプリケーション・サーバーに接続するアプリケーション・リクエスターにセッション限度を定義します。 VTAM APPL ステートメントは、すべてのパートナー・システムに省略時セッション制限を定義します。特定のパートナーの固有の省略時値を確立するには、アプリケーション・サーバー・サイトで稼働している AVS 仮想計算機から AGW CNOS コマンドを使用してください。 (セッション限度は、通常アプリケーション・リクエスターにより要求されます。)

    RU サイズ、セッション限度、および歩調合わせカウントを選択した後は、 VTAM IOBUF プールに与えるこれらの値の影響を考慮してください。

サーバー名の RESID へのマッピング

資源 ID (RESID) は、トランザクション・プログラム名の VM 用語です。 VM 環境では、これは一般に 8 バイト以下の長さの英数字名で定義されます。管理を簡潔にするために、通常は RESID をサーバー名と同一にして定義します。 図 34 に、RESID 名前ファイルの例を示します。

図 34. RESID 名前ファイルの例

 RESID  NAMES    A1  V 132  Trunc=132 Size=4  Line=1 Col=1 Alt=3                
====>                                                                           
00001  :nick.MTLTPN                                                             
00002                 :dbname.MONTREAL_SALES_DB                                 
00003                 :resid.SALES                                              
00004                                                                           

この dbname および RESID を (TPN として) 定義する通信ディレクトリー項目についての詳細は、 図 33 を参照してください。アプリケーション・サーバー名を RESID と同じにできない場合、 DB2 (VM 版) アプリケーション・サーバーは RESID NAMES を使用して、マッピングを行います。このマッピングは、以下の場合に必要です。

インストール時には、省略時解釈では SQLDBINS EXEC で指定されたサーバー名を RESID として使用します。 RESID NAMES ファイルにマッピング項目を作成するには、 SQLDBINS に RESID パラメーターを指定します。

SQLSTART DB(server_name) を使用してデータベースを開始する場合、 DB2 (VM 版) は対応する RESID を見つけて、これが VM の制御対象の資源であるということを VM に伝えます。項目が RESID NAMES ファイルに見つからない場合には、 DB2 (VM 版) は RESID がサーバー名と同一であると想定して、 VM にそのように伝えます。詳細については、 DB2 システム管理 (VM 版) を参照してください。

DB2 (VM 版) アプリケーション・サーバーの準備および開始

DB2 (VM 版) アプリケーション・サーバーが、 DRDA サポートをインストールしていない場合があります。以下のステップに従って、 DRDA 通信用に DB2 (VM 版) アプリケーション・サーバーを準備します。

  1. ARISDBMA exec を使用して、DRDA サポートをインストールします。

    詳細については、 VM/ESA System Administration を参照してください。

  2. ARISDBMA を出したあとに、DB2 (VM 版) ARISQLLD LOADLIB を再作成します。詳細については、 DB2 システム管理 (VM 版) の『DRDA 環境の使用』の章を参照してください。

機密保護の提供

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

エンド・ユーザー名

SQL および LU 6.2 では、エンド・ユーザーには 1〜8 バイトのユーザー ID が割り当てられます。このユーザー ID は特定のオペレーティング・システムでは固有でなければなりませんが、 SNA ネットワーク全体で固有である必要はありません。命名の対立を解消するため、 DB2 (VM 版) は AVS により提供されたユーザー ID 変換機能を任意選択で使用できます。このとき、以下の条件を満たしていなければなりません。

SECURITY=SAME オプションを使用して AVS を介して接続が経路指定される場合、 AVS ユーザー ID 変換が必要になります。 AGW ADD USERID コマンドは、AVS マシンから出されますが、特定のリモート LU または AVS ゲートウェイから接続しているユーザーへの機密保護許可を提供しなければなりません。マッピングが、 SECURITY=SAME を使用して接続するすべてのインバウンド LU およびユーザー ID に対して存在しなければなりません。コマンドには柔軟性があり、すべてのユーザー ID を特定の LU から受け入れることも、すべてのリモート LU から包括的に受け入れることもできます。あるいは、特定の LU から特定のセットのユーザー ID だけを受け入れることもできます。

AGW ADD USERID コマンドを使用してインバウンド (検査済み) ユーザー ID をローカル AVS マシンで許可した場合は、妥当性検査はホストにより実行されません。つまり、権限を受けた ID はホストになければならないわけではなく、いずれにしても接続は受け入れられます。

現行の AVS ユーザー ID 許可は以下の 2 つの方法で変更できます。

たとえば、異なる都市の同一のユーザー ID を例にして、 AVS 変換機能が名前の対立を解決する方法を示します。トロントのシステムに JONES という ID のユーザーがおり、モントリオールのシステムにも同一の ID のユーザーがいるとします。モントリオールの JONES が、トロントのシステムにあるデータにアクセスしたい場合、トロントのシステムの以下のアクションによって命名の対立を解消し、モントリオールの JONES がトロントの JONES に授与された特権を使用しないようにします。

  1. AVS 操作員は AGW ADD USERID コマンドを使用して、モントリオールのユーザーの ID をローカル・ユーザー ID に変換しなければなりません。たとえば、操作員が AGW ADD USERID MTLGATE JONES MONTJON を出すと、モントリオールのユーザーはトロントのシステムでは MONTJON として認識されます。モントリオールの他のすべてのユーザーが接続 (リモート LU MTLGATE を介した接続) を許可されており、さらにローカルではリモート・ユーザー ID で認識されている場合には、操作員はコマンド AGW ADD USERID MTLGATE * = を出さなければなりません。これらの AVS コマンドを AVS プロファイルに追加して、 AVS が始動したときに自動的に実行できるようにすることもできます。
  2. DBA は DB2 (VM 版) GRANT コマンドを使用して、変換されたユーザー ID (この特定のケースでは MONTJON) に対して特権のセットを授与しなければなりません。

これらの処置はモントリオールのシステムでも実行でき、トロントの JONES がモントリオールのシステムのリモート・データにアクセスするときに、モントリオールの JONES に授与された特権を使用しないようにすることができます。

ユーザー ID 変換をサポートする AVS コマンドは、 VM/ESA 接続計画、管理および操作 で説明されています。

ネットワーク機密保護

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

DB2 (VM 版) のセッション・レベル機密保護を指定する方法についての詳細は、 ネットワーク機密保護を参照してください。 DB2 (VM 版) アプリケーション・サーバーは DB2 (VM 版) アプリケーション・リクエスターと同様の方法で、セッション・レベル機密保護を使用します。

アプリケーション・リクエスターは、検査済みユーザー ID (SECURITY=SAME) またはユーザー ID とパスワード (SECURITY=PGM) のいずれかを送信できます。ユーザー ID とパスワードが送信された場合、 CP、RACF、または同等のものがこれらをアプリケーション・サーバー・ホストの VM ディレクトリーによって検査します。妥当性検査に失敗すると、接続要求が拒否されます。そうでなければ、受け入れられます。要求にユーザー ID しか含まれていない場合、 DB2 (VM 版) はユーザー ID の妥当性検査をしないで要求を受け入れます。
注:VM/ESA は暗号化をサポートしないため、DB2 (VM 版) は暗号化機能を提供しません。

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

DB2 (VM 版) アプリケーション・サーバーは、 VM から受け取ったユーザー ID にデータベースへアクセスする CONNECT 権限があるかどうかを検査し、この権限がない場合には接続を拒否します。

データベース資源の所有者として、DB2 (VM 版) アプリケーション・サーバーは、そこにある SQL オブジェクトに対してデータベース機密保護機能を制御します。 DB2 (VM 版) により制御されるオブジェクトへのアクセスは特権のセットを使用して制御されます。この特権は、DB2 (VM 版) システム管理者または特定のオブジェクトの所有者により授与されます。 DB2 (VM 版) アプリケーション・サーバーは、2 つのクラスのオブジェクトを制御します。

機密保護サブシステム

DB2 (VM 版) アプリケーション・サーバーによるこのサブシステムの使用は、任意選択です。アプリケーション・サーバーがアプリケーション・リクエスター LU 名の識別項目を検査する必要がある場合には、 VTAM が機密保護サブシステムを呼び出してパートナー LU 検査交換を実行するようにします。 DB2 (VM 版) アプリケーション・サーバーがインバウンド分散データベース要求を受信するために使用するゲートウェイの VTAM APPL ステートメントの VERIFY パラメーターで指定されている値にしたがって、パートナー LU 検査を実行するかどうかが決まります。

機密保護サブシステムを CP によって呼び出して、アプリケーション・リクエスターから送信されたユーザー ID およびパスワードを妥当性検査することもできます。機密保護サブシステムが RACF であり RACF システム・プロファイルがない場合は、妥当性検査は RACF により実行されます。 RACF システム・プロファイル (たとえば RACFPROF) がある場合、以下の指示に従って RACF からこの妥当性検査を要求してください。

   RALTER VMXEVENT RACFPROF DELMEM (APPCPWVL/NOCTL
   RALTER VMXEVENT RACFPROF ADDMEM (APPCPWVL/CTL
   SETEVENT REFRESH RACFPROF

データの表示

インストールには、最も適切な省略時 CHARNAME および CCSID を選択しなければなりません。最も適切な値を使用すると、文字データ表記の保全性を確保し、 CCSID 会話に関連したパフォーマンス・オーバーヘッドを減少させます。

たとえば、ご使用の DB2 (VM 版) アプリケーション・サーバーが、端末制御機構がコード・ページ 37 および米国英語の文字セット 697(CP/CS 37/697) で生成されるローカル・ユーザーにのみアクセスされる場合は、アプリケーション・サーバーの省略時 CHARNAME を ENGLISH に設定してください。 CP/CS 37/697 が 37 の CCSID 対応し、これは ENGLISH の CHARNAME に対応するからです。

不必要な CCSID 変換を減らすため、アプリケーション・サーバーの省略時 CCSID を、アプリケーション・サーバーに最も頻繁にアクセスするアプリケーション・リクエスターの CCSID と同じにするように選択してください。

これら 2 つの目標が対立する場合の例を次に示します。

システムの現行の CCSID を表示するには、SYSTEM.SYSOPTIONS 表を照会します。アプリケーション・サーバーの省略時 CCSID は、通常 CCSIDMIXED の値です。この値がゼロの場合、システムの省略時 CCSID は CCSIDSBCS の値です。この表の CHARNAME、CCSIDSBCS、 CCSIDMIXED、および CCSIDGRAPHIC 値は、データベースが開始されるたびに、システム省略時値として使用されている値に更新されます。この表の値は、常にシステム省略時値とは限りません。勧められていませんが、DBA 権限のあるユーザーが、これらの値を変更した可能性があります。アプリケーション・サーバーの省略時 CCSID を変更するには、アプリケーション・サーバーが次に始動するときに、 SQLSTART EXEC の CHARNAME パラメーターを指定しなければなりません。詳細については、 VM/ESA System Administration を参照してください。

新しくインストールされたデータベースでは、アプリケーション・サーバーの省略時 CHARNAME は INTERNATIONAL であり、アプリケーション・サーバーの省略時 CCSID は 500 です。これはおそらく、ご使用のシステムでは正しくない でしょう。移行システムの省略時 CHARNAME は ENGLISH であり、省略時 CCSID は 37 です。

DB2 (VM 版) DRDA アプリケーション・サーバーを使用可能にするためのチェックリスト

以下のチェックリストは DRDA 通信用の DRDA アプリケーション・サーバーを使用可能にするためのステップを要約したものですが、初めに次のような前提事項があります。まず、 VM システムがテレプロセシング・アクセス方式として ACF/VTAM を使用してインストールされていること、そして、リモート・システムとの通信に必要な VTAM 定義 (NCP 定義など) がすでに完了していることです。

  1. ローカル AVS ゲートウェイを VTAM に定義する。
  2. CRR 回復サーバーを作成する。 CRR 回復サーバーが指定する LUNAME が、 SYNCLVL=SYNCPNT 会話を処理する AVS ゲートウェイの名前と必ず一致するようにしてください。
  3. ARISDBMA exec を使用して、 DRDA サポートを DB2 (VM 版) アプリケーション・サーバーにインストールする。
  4. IUCV *IDENT ステートメントを VM サーバー・マシンの CP ディレクトリーに追加して、グローバル資源として識別できるようにする。
  5. ローカル・ユーザー ID およびパスワードを、リモート・アプリケーション・リクエスターが使用する CP に定義する。必要な場合、AVS AGW ADD USERID コマンドを使用して、リモート・ユーザー ID をローカル VM ユーザー ID にマップしてください。
  6. アプリケーション・リクエスターが要求する各モードごとに、 VTAM モード名表に項目を作成する。
  7. VTAM および AVS を始動して、 VM アプリケーションが SNA ネットワークを介してリモート通信できるようにする。
  8. アプリケーション・リクエスターがあるすべてのパートナー・システムにセッション限度を設定する。
  9. DBNAME、PROTOCOL および SYNCPNT パラメーターを入力して、 DB2 (VM 版) アプリケーション・サーバーを始動する。データベース・マネージャーが始動している場合、そのデータベース・マネージャーは必ず GLOBAL として識別されるようにしてください。
  10. DB2 (VM 版) アプリケーション・サーバーにアプリケーションを準備する。


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