コネクティビティー 補足

VM 環境でのアプリケーション・リクエスターのセットアップ

DB2 (VM 版) には、DRDA アプリケーション・リクエスター・サポートが、アプリケーションのあるエンド・ユーザーの仮想計算機上に存在するリソース・アダプターの統合部分として実装されています。ローカルのデータベース・マネージャーの仮想計算機がアクティブではないときでも、アプリケーション・リクエスター・サポートを使用できます。 DRDA アプリケーション・リクエスター・サポートは、 protocol(auto) または protocol(drda) を指定して SQLINIT EXEC を実行することにより活動化できます (アプリケーションのプリプロセスまたは実行オプションを参照)。

アプリケーション・リクエスターとして動作する場合、 DB2 (VM 版) は DB2 (VM 版) アプリケーション・サーバーまたは DRDA アーキテクチャーをサポートする他の製品サーバーに接続できます。 DB2 (VM 版) アプリケーション・リクエスターを使用して分散データベースにアクセスするには、以下のようにする方法を知っている必要があります。

ネットワーク情報の提供

分散データベース環境の処理の多くで、ネットワーク内の他の場所との間でメッセージが交換される必要があります。この処理を正しく実行するために、以下のステップに従ってください。

  1. ローカル・システムの定義
  2. リモート・システムの定義
  3. 通信サブシステムの定義
  4. RU サイズおよび歩調合わせの設定
  5. DB2 (VM 版) アプリケーション・リクエスターの準備

ローカル・システムの定義

DB2 (VM 版) アプリケーション・リクエスターと DB2 (VM 版) アプリケーション・サーバーは、互いに独立しています。 DB2 (VM 版) アプリケーション・リクエスターは、ローカルまたはリモート・アプリケーション・サーバーへの接続要求を直接指示します。しかし、インバウンド接続要求の宛先としてそれ自身を定義することはありません。 DB2 (VM 版) アプリケーション・サーバーだけがインバウンド接続要求を受け入れる (または拒否する) ことができます。そのため、DB2 (VM 版) アプリケーション・リクエスターは、 DB2 ユニバーサル・データベース (OS/390 版) がするように RDB_NAME および TPN を自分で識別することはできません。

以下のように、DB2 (VM 版) アプリケーション・リクエスターを SNA ネットワークに定義してください。

  1. VTAM APPL 定義ステートメントを使用して、AVS ゲートウェイ名を定義する。

    アプリケーション・リクエスターはゲートウェイ名 (たとえば、LU 名) を定義し、アウトバウンド要求をネットワークに経路指定できるようにしていなければなりません。 図 30 には、この例が示されています。これらのステートメントは、VTAM 仮想計算機にあります。 VTAM が開始すると、ゲートウェイはネットワークに識別されますが、制御 AVS 仮想計算機が開始するまで活動状態にはなりません。各 AVS 仮想計算機は、複数のゲートウェイを VM ホストに定義できます。

    図 30. AVS ゲートウェイ定義の例

              VBUILD TYPE=APPL
     *************************************************************
     *                                                           *
     *     Gateway Definition for Toronto DB2 for VM System      *
     *                                                           *
     *************************************************************
     TORGATE  APPL  APPC=YES,                                    X
                    AUTHEXIT=YES,                                X
                    AUTOSES=1,                                   X
                    DMINWNL=10,                                  X
                    DMINWNR=10,                                  X
                    DSESLIM=20,                                  X
                    EAS=9999,                                    X
                    MAXPVT=100K,                                 X
                    MODETAB=RDBMODES,                            X
                    PARSESS=YES,                                 X
                    SECACPT=ALREADYV,                            X
                    SYNCLVL=SYNCPT,                              X
                    VPACING=2
    

    以下のリストに、本書のトピックにあてはまる VTAM APPL ステートメント・キーワードを説明します。 (VTAM APPL ステートメントはここに説明したものよりももっと多くのキーワードをサポートしています。)

    TORGATE
    VTAM は、ゲートウェイ (LU) 名として APPL ステートメント・ラベルを使用します。 図 30 では、ゲートウェイ TORGATE が定義されています。 VTAM APPL ステートメントは NETID を指定しません。 NETID は、VTAM システムのすべての VTAM アプリケーションに自動的に割り当てられます。

    AUTOSES=1
    ゲートウェイ TORGATE は、 APPC セッション数変更 (CNOS) コマンドを出すときに、 1 つの SNA 回線争奪勝者セッションが自動的に開始することを指定します。 CNO 処理が失敗したときに AVS がすべての場合に通知を受けるように、 AUTOSES に非ゼロ値を提供しなければなりません。任意の 2 つの分散データベース・パートナー間のすべての APPC セッションを自動的に開始する必要はありません。 AUTOSES 値が回線争奪勝者の限度 (DMINWNL) より小さい場合には、分散データベース・アプリケーションが必要とするまで、 VTAM は残りのセッションの開始を遅らせます。

    DMINWNL=10
    ゲートウェイ TORGATE は、この DB2 (VM 版) システムが少なくとも 10 個のセッションでの回線争奪勝者であることを指定します。 CNOS 処理は DMINWNL パラメーターを省略時値として使用しますが、 AVS 仮想計算機から AGW CNOS コマンドを出すことによって、所定のパートナーでこれを一時変更することができます。

    DMINWNR=10
    ゲートウェイ TORGATE は、このパートナー・システムが少なくとも 10 個のセッションでの回線争奪勝者であることを指定します。 CNOS 処理は DMINWNR パラメーターを省略時値として使用しますが、 AVS 仮想計算機から AGW CNOS コマンドを出すことによって、指定パートナーでこれを一時変更することができます。

    DSESLIM=20
    ゲートウェイ TORGATE と特定のモード・グループ名のすべてのパートナー分散システムとの間に許可されているセッション (勝者と敗者の両方) の合計数は、20 です。 CNOS 処理は DSESLIM パラメーターを省略時値として使用しますが、 AVS 仮想計算機から AGW CNOS コマンドを出すことによって、指定パートナーでこれを一時変更することができます。パートナーが DSESLIM、 DMINWNL、または DMINWNR パラメーターにより指定されたセッションの数をサポートできない場合には、 CNOS 処理はパートナーが受け入れ可能なこれらのパラメーターの新しい値を折衝します。

    EAS=9999
    この VTAM LU で必要とされるセッションの合計数の見積もり。

    MODETAB=RDBMODES
    VTAM モード表の名前は、RDBMODES です。この表には、このゲートウェイが他の分散データベース・パートナーと通信するために使用できるすべてのモード名が含まれています。

    SECACPT=ALREADYV
    これは機密保護受諾パラメーターであり、リモート・パラメーターから分散データベース要求で提示されたときにこのゲートウェイがサポートする最高の APPC 会話機密保護レベルを識別します。 SECACPT=ALREADYV をお勧めします。 ALREADYV オプションは以下の機密保護レベルをサポートします。
    • SECURITY=NONE、機密保護情報を含めないようにする要求。 DB2 (VM 版) は、この機密保護レベルを使用して DRDA 要求を拒否します。
    • SECURITY=PGM、リクエスターのユーザー ID およびパスワードを含む要求。 DB2 (VM 版) は、この機密保護レベルを使用して DRDA 要求を受け入れます。
    • SECURITY=SAME は、リクエスターのユーザー ID だけを含む検査済みの要求を指示します。

    SYNCLVL=SYNCPT
    SYNCLVL パラメーターは AVS の同期サポート・レベルを指定します。 SYNCPT の値は NONE、CONFIRM および SYNCPT の同期レベルがサポートされていることを示しています。 AVS ゲートウェイが DB2 (VM 版) サーバーの DRDA-2 分散作業単位活動で使用される場合は、値として SYNCPT を指定してください。分散作業単位活動が行われない場合は、 CONFIRM (NONE および CONFIRM がサポートされているが、 SYNCPT がサポートされていない) を指定してください。

    VERIFY=NONE
    この DB2 (VM 版) システムで必要な SNA セッション機密保護の (パートナー LU 検査) レベルを識別します。 NONE 値は、パートナー LU 検査が必要ではないことを示しています。

    DB2 (VM 版) は VERIFY キーワードの選択を制限することはありませんが、実行中の VTAM バージョンはこの選択に影響を与えることがあります。信頼性に欠けるネットワークでは、 DB2 (VM 版) は VERIFY=REQUIRED をコーディングすることをお勧めします。 VERIFY=OPTIONAL を選択すると、 VTAM はサポートを提供するパートナーにのみパートナー LU 検査を実行します。 VERIFY=REQUIRED を指定すると、パートナー LU 検査を実行できないパートナーを VTAM が拒否することになります。

    VPACING=2
    このパラメーターは、パートナー LU とこのゲートウェイとの間で使用されるセッション歩調合わせカウントを設定します。セッション歩調合わせは、分散データベース・システムにたいへん重要です。
  2. ゲートウェイを活動化します。

    ゲートウェイの活動化は、 DB2 (VM 版) アプリケーション・リクエスターと同じホスト (または同じ TSAF コレクションにある他のホスト) で稼働している AVS 仮想計算機から実行されます。 AVS マシンのプロファイルに AGW ACTIVATE GATEWAY GLOBAL コマンドを含めるか、このコマンドを AVS マシン・コンソールから対話式に出して、 AVS が開始するたびにゲートウェイが自動的に使用できるようにしてください。

  3. ゲートウェイとその各パートナー LU との間のセッションの数を折衝するには、 AGW CNOS コマンドを使用してください。

    AVS ゲートウェイ・マシンの CP ディレクトリーでの MAXCONN 値が、必要なセッションの合計数をサポートするのに十分な大きさであることを確認してください。

    AGW DEACTIVE GATEWAY コマンドを AVS 仮想計算機から出しそのゲートウェイを使用不可にします。ゲートウェイ定義はそのままになります。 AGW ACTIVATE GATEWAY GLOBAL コマンドを使用すれば、この時点でゲートウェイは再び使用可能になります。

    AVS コマンド形式についての詳細は、 VM/ESA 接続計画、管理および操作 を参照してください。

  4. インストール時に VTAM NETIDDB2 (VM 版) DBMS に定義されたことを確認してください。

    アプリケーション・リクエスターが存在するホスト (または同じ TSAF コレクション内の他のホスト) の NETID は、要求がネットワークに入れられるときに VTAM によって提供されます。 NETID は CMS ファイル SNA NETID に保管されて、アプリケーション・リクエスターによってアクセスされる DB2 (VM 版) 実動ディスク内に存在します。アプリケーション・リクエスターはこの NETID を、会話ごとに送られる LUWID の生成に使用します。

リモート・システムの定義

VTAM が望ましいネットワーク宛先を位置指定できるような LU 名を登録することにより、リモート・システムを定義しなければなりません。 AVS が開始すると、リモート・システムはグローバル・ゲートウェイ名 (LU 名) を識別します。この名前は SQL 要求を VTAM へのネットワークに経路指定するのに利用できます。インバウンド要求とアウトバウンド要求の両方が適切な LU 名に経路指定されるためには、ゲートウェイ名は、ローカル VTAM システムにより認識される LU のセット内で固有でなければなりません。これは、ユーザー・ネットワークを通してゲートウェイ名の固有性を確認する最善の方法です。これにより、VTAM 資源定義プロセスが単純になります。

DB2 (VM 版) アプリケーションがリモート・システムからデータを要求すると、 DB2 (VM 版) は CMS 通信ディレクトリーでリモート・システムに関する以下の情報を検索します。

CMS 通信ディレクトリーは、ファイル・タイプ NAMES の CMS ファイルであり、 DB2 (VM 版) システム管理者により作成および管理されます。管理者として、XEDIT を使用してこのファイルを作成し、おのおのの潜在的な DRDA パートナーを識別するために適切な項目を追加できます。ディレクトリーの各項目は、タグとそれに関連する値のセットです。 図 31 は、項目の例を示しています。検索が実行されると、一致が見つかるかファイルの終了に達するまで、ファイルの各項目の :dbname タグ値と検索キーが比較されます。 図 31 の例では、トロントの販売責任者は MONTREAL_SALES データベースからデータをリモート・アクセスしてモントリオール支店の月別販売報告書を作成したいとします。

図 31. CMS 通信ディレクトリーの項目の例

 SCOMDIR  NAMES    A1  V 132  Trunc=132 Size=10 Line=1 Col=1 Alt=8              
====>                                                                           
00001  :nick.MTLSALES                                                           
00002                 :tpn.SALES                                                
00003                 :luname.TORGATE MTLGATE                                   
00004                 :modename.BATCH                                           
00005                 :security.PGM                                             
00006                 :userid.SALESMGR                                          
00007                 :password.GREATMTH                                        
00008                 :dbname.MONTREAL_SALES                                    
00009                                                                           

:tpn タグは、アプリケーション・サーバーを活動化するトランザクション・プログラム名を識別します。 :luname タグの最初の部分で、 SNA ネットワークへのアクセスを得るために使用される AVS ゲートウェイ (ローカル LU) を識別します。 2 番目の部分はリモート LU 名を識別します。 :modename タグは、ローカル LU とリモート LU との間に割り当てられるセッションの特性を定義する VTAM モードを識別します。要求単位 (RU) サイズ、歩調合わせ、およびサービス・クラス (COS) はそのような特性の例です。 :security タグは、アプリケーション・リクエスターをアプリケーション・サーバーに接続する会話で使用する機密保護のレベルを示します。

CMS 通信ディレクトリーは、特定の VM システム内のすべてのアプリケーション・リクエスターからアクセス可能な共通システム・ディスク上にあります。 VTAM を介したリモート・アクセスの必要なプログラムまたは製品は、CMS 通信ディレクトリーを使用できます。

2 つのレベルの CMS 通信ディレクトリーにアクセスできます。システム・レベルおよびユーザー・レベルです。たとえば、システム・レベルのディレクトリーを、特定の VM システム内のすべてのアプリケーション・リクエスターからアクセス可能な共通システム・ディスク上に作成できます。また、自分のユーザー・レベル・ディレクトリーを作成して、既存の項目を一時変更したり、システム・レベル・ディレクトリーにはない新しい項目を導入することもできます。ユーザー・レベル・ディレクトリーが最初に検索されます。検索に失敗した場合には、システム・レベル・ディレクトリーが検索されます。システム・レベル・ディレクトリーは、ユーザー・レベル・ディレクトリーの拡張です。これは、ユーザー・レベル・ディレクトリーに値が見つからない場合にのみ検索されます。

これらのディレクトリーはそれぞれ、 CMS SET COMDIR コマンドによってアプリケーションに識別され、活動化されます。たとえば、以下のコマンド順序を使用して、システムおよびユーザー・レベル・ディレクトリー (それぞれ S および A ミニディスクにある) を識別できますが、検索にはシステム・レベル・ディレクトリーだけを活動化するよう選択します。

   SET COMDIR FILE SYSTEM SCOMDIR NAMES S
   SET COMDIR FILE USER UCOMDIR NAMES A
   SET COMDIR OFF USER

CMS 通信ディレクトリーについては、 VM/ESA 接続計画、管理および操作 で詳細に説明されています。 CMS SET COMDIR コマンドについては、 VM/ESA CMS コマンド解説書 で説明されています。

通信サブシステムの定義

VM 環境では、構成要素の組み合わせによって通信管理を実行します。異種 DRDA システム間の通信に関連する構成要素は、 APPC/VM、CMS 通信ディレクトリー、TSAF、AVS、および VTAM です。

APPC/VM は、 DB2 (VM 版) アプリケーション・リクエスターが通信サービスを要求するときに使用する LU 6.2 アセンブラー・レベルの API です。 CMS 通信ディレクトリーは、分散パートナー・システムの経路指定および機密保護情報を提供します。 AVS はゲートウェイを活動化し、アウトバウンド APPC/VM フローを APPC/VTAM フローに、インバウンド APPC/VTAM フローを APPC/VM フローに変換できます。

APPC/VM、TSAF、および AVS は、適切な DRDA パートナーに要求を経路指定する上で、 CMS 通信ディレクトリー、VTAM、および *IDENT に依存しています。

VTAM が CMS 通信ディレクトリーで識別されるパートナー・アプリケーションと通信するためには、以下の情報を提供しなければなりません。

  1. 各アプリケーション・リクエスターおよびアプリケーション・サーバーの LU 名を VTAM に定義します。リモート・システムが論理的および物理的に VTAM システムに接続されている状態により、これらの定義の配置および構文は異なります。
  2. CMS 通信ディレクトリーで指定される各モード名の VTAM モード表に項目を作成します。これらの項目には、特定のモード名の要求単位 (RU) サイズ、歩調合わせサイズ、およびサービスのクラスを説明します。
  3. パートナー LU 検査を使用する場合には (セッション・レベル機密保護)、検査アルゴリズムに VTAM および RACF プロファイル (または同等のもの) を提供してください。

AVS セッション限度の考慮事項

アプリケーション・リクエスターが AVS を使用してリモート・アプリケーション・サーバーと通信するときに、接続が開始されます。この接続が原因で確立されたセッション限度を超えると、セッションが利用可能になるまで、AVS は接続を保留状態に据え置きます。セッションが利用可能になると、AVS はセッションに保留の接続を割り当て、制御はユーザー・アプリケーションに戻されます。この状況を回避するため、セッション限度を増やしてさらに接続できるようにピーク時の使用を計画してください。 AVS マシンの CP ディレクトリーでの MAXCONN 値が、 APPC/VM 接続によるピーク時の使用をサポートするのに十分な大きさであることを確認してください。

RU サイズおよび歩調合わせの設定

VTAM モード表で定義する項目によって、要求単位 (RU) サイズおよび歩調合わせカウントを指定します。これらの値を正しく定義できていないと、すべての VTAM アプリケーションに悪影響を与える可能性があります。

要求単位 (RU) サイズ、セッション限度、および歩調合わせカウントを選択した後、これらの値が既存の SNA ネットワークに与える影響を考慮してください。新しい分散データベース・システムをインストールするときには、以下の項目を復習してください。

DB2 (VM 版) アプリケーション・リクエスターの準備

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

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

    詳細については、 DB2 システム管理 (VM 版) を参照してください。

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

機密保護の提供

リモート・システムが SQL アプリケーションに代わって分散データベース処理を実行する場合には、アプリケーション・リクエスター、アプリケーション・サーバー、およびそれらに接続しているネットワークの機密保護要件を満たさなければなりません。これらの要件は、以下のカテゴリーのいくつかに分けられます。

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

SQL および LU 6.2 では、エンド・ユーザーには 1〜8 文字のユーザー ID が割り当てられます。このユーザー ID 値は、特定のオペレーティング・システムで固有でなければなりませんが、 SNA ネットワーク全体で固有でなければならないわけではありません。たとえば、TORONTO システムで JONES というユーザーがいて、 MONTREAL システムでまた JONES というユーザーがいてもかまいません。この 2 人のユーザーが同一の人であれば、対立は起きません。しかし、TORONTO の JONES が MONTREAL の JONES と同一人物でない場合、 SNA ネットワーク (およびそのネットワークの分散データベース・システム) は、 TORONTO の JONES と MONTREAL の JONES とを識別できません。この状況を避けるための処置をとらない場合には、 TORONTO の JONES は MONTREAL の JONES に与えられた特権を使用できます。この逆のことも起こります。

名前の対立を解消するため、DB2 (VM 版) はエンド・ユーザー名変換のサポートを提供します。しかし、システムはユーザー ID の変換を強制しません。システム強制変換が必要な場合は、アプリケーション・サーバーで適切なインバウンド変換が実行されていることを確認しなければなりません。

アウトバウンド変換 は、CMS 通信ディレクトリーを使用して実行されます。 CMS 通信ディレクトリーの項目に、:security.PGM を指定しなければなりません。この場合には、 :userid および :password タグに対応する値が接続要求でのリモート・サイト (アプリケーション・サーバー) に流れます。

図 32 に示されている項目を作成すると、ローカル (TORONTO) システムの JONES という ID のユーザーが MONTREAL システムの MONTREAL_SALES_DB アプリケーション・サーバーに接続したときに、ユーザー ID JONEST にマップされます。このようにして、ユーザー ID のあいまいさが解消されます。

図 32. アウトバウンド名前変換

 UCOMDIR  NAMES    A1  V 132  Trunc=132 Size=10 Line=1 Col=1 Alt=8              
====>                                                                           
00001  :nick.MTLSALES                                                           
00002                 :tpn.SALES                                                
00003                 :luname.TORLU MTLGATE                                     
00004                 :modename.BATCH                                           
00005                 :security.PGM                                             
00006                 :userid.JONEST                                            
00007                 :password.JONESPW                                         
00008                 :dbname.MONTREAL_SALES_DB                                 
00009                                                                           

ネットワーク機密保護

リモート・サイト (アプリケーション・サーバー) でアプリケーション・リクエスターを表すエンド・ユーザー名を選択した場合、アプリケーション・リクエスターは、必要な LU 6.2 ネットワーク機密保護情報を提供しなければなりません。 LU 6.2 は、主に 3 つのネットワーク機密保護機構を提供します。

アプリケーション・サーバーにはデータベース資源を管理する責任があるので、アプリケーション・サーバーは、どのネットワーク機密保護メカニズムをアプリケーション・リクエスターが提供しなければならないかを指示します。 :security タグに適切な値を設定して、アプリケーション・リクエスターの通信ディレクトリーにアプリケーション・サーバーの機密保護要件を記録しなければなりません。

DRDA によりサポートされる SNA 会話レベル機密保護オプションは、以下のとおりです。

SECURITY=SAME
これは、検査済みの機密保護としても知られています。それは、エンド・ユーザーの ID (ログオン ID) だけがリモート・システムに送信されるためです。パスワードは送信されません。このレベルの会話機密保護は、アプリケーション・サーバー用にアプリケーション・リクエスターの通信ディレクトリーで :security.SAME が指定された場合に、使用されます。このオプションが使用されているときには、アウトバウンド・エンド・ユーザー名変換は実行されません。リモート DRDA サイトに送信されるユーザー ID は、CMS ユーザーのログオン ID です。 CMS 通信ディレクトリーの :userid タグは、:security.SAME では無視されます。

SECURITY=PGM
このオプションを使用すると、エンド・ユーザー ID とパスワードの両方が妥当性検査のためにリモート・システム (アプリケーション・サーバー) に送信されます。この機密保護オプションは、アプリケーション・リクエスターの CMS 通信ディレクトリー項目に :security.PGM が指定されるときに使用されます。このオプションが使用されているときには、アウトバウンド・エンド・ユーザー名変換が実行されます。

DB2 (VM 版) は、パスワード暗号化をサポートしません。このパスワードは :password タグに指定することもできますし、エンド・ユーザーの CP ディレクトリー項目に APPCPASS ディレクトリー・ステートメントを使用して保管することもできます。パスワードの機密保護を最高にしたい場合には、APPCPASS ステートメントをお勧めします。パスワードが CMS 通信ディレクトリー項目に指定されていない場合、ユーザーのシステム (VM) ディレクトリーで APPCPASS ステートメントが探索されます。

APPCPASS ステートメント

VM で提供される APPCPASS ステートメントは、アプリケーション・リクエスターがアプリケーション・サーバーへの接続に使用するユーザー ID およびパスワードの機密保護を最大にします。以下のいずれかの方法で機密保護情報を保管できるという点で、APPCPASS には柔軟性があります。

図 33 では、ユーザー ID がユーザーの通信ディレクトリーに保管されており、パスワードがユーザーの VM ディレクトリー項目に保管されている場合の例を示しています。通信ディレクトリー項目では、ユーザー ID は MTLSOU に設定されていますが、パスワードは設定されていません。パスワードは、ユーザーの VM ディレクトリー項目に保管されています。

図 33. パスワードなしの通信ディレクトリー項目の例

 UCOMDIR  NAMES    A1  V 132  Trunc=132 Size=8  Line=1 Col=1 Alt=8              
====>                                                                           
00001  :nick.MTLSALES                                                           
00002                 :tpn.SALES                                                
00003                 :luname.TORGATE MTLGATE                                   
00004                 :modename.BATCH                                           
00005                 :security.PGM                                             
00006                 :userid.MTLSOU                                            
00007                 :password.                                                
00008                 :dbname.MONTREAL_SALES_DB                                 
00009                                                                           

APPC/VM がアプリケーション・リクエスターとアプリケーション・サーバーとの間の接続を会話 SECURITY=PGM を使用して開始するとき、 :userid および :password タグの値が読み取られてアプリケーション・サーバーに渡されます。これらのタグの一方または両方がブランクに設定されている場合には、ユーザーの VM ディレクトリー項目で欠落情報を探索します。この場合、以下のように VM ディレクトリー項目に APPCPASS ステートメントがなければなりません。

    APPCPASS TORGATE MTLGATE MTLSOU Q6VBN8XP

このステートメントは APPC/VM に、 (ローカルの) AVS ゲートウェイ TORGATE を介して接続を要求しているユーザー (アプリケーション・リクエスター)、 MTLGATE という名前のパートナー LU、およびユーザー ID MTLSOU がパスワード Q6VBN8XP をアプリケーション・サーバーに送る必要があることを伝えます。このユーザーは、アプリケーション・サーバーで 2 つの識別子で識別されます。

VM ディレクトリーに APPCPASS ステートメントを配置することは、エンド・ユーザーのタスクではありません。エンド・ユーザーは、これを実行するように VM システム・プログラマーに要求しなければなりません。

会話レベル機密保護および APPCPASS ステートメントについての詳細は、 VM/ESA 接続計画、管理および操作 を参照してください。

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

DRDA 内の全体的な分散データベース機密保護フレームワークの一部として、アプリケーション・リクエスターはどのエンド・ユーザーに分散データベース要求を出すことを許可するかを制御する役割を果たします。 DB2 (VM 版) では、アプリケーション・リクエスターは以下の 3 つの方法で分散データベースの機密保護に貢献します。

アウトバウンド・ユーザー名変換
アウトバウンド・ユーザー名変換を使用すると、要求しているエンド・ユーザーの ID にしたがって、特定のアプリケーション・サーバーへのアクセスを制御できます。 DB2 (VM 版) は、リモート・サイトに要求を送信する前にエンド・ユーザーの名前を変換しようとします。ただし、VM アプリケーション・リクエスターのユーザーが CMS ユーザー通信ディレクトリーを使用してアウトバウンド変換を上書きする可能性があるので、最良の方法は、アプリケーション・サーバーが come-from 検査およびインバウンド変換を行うようにすることです。

アプリケーション・プリプロセス
エンド・ユーザーは、特定のアプリケーション・サーバーへのリモート・アプリケーションをプリプロセスします。これは、 DB2 (VM 版) の SQLPREP EXEC またはデータベース・サービス・ユーティリティー (DBSU) RELOAD PACKAGE コマンドを使用して行います。 DB2 (VM 版) は、これらのサービスの使用を制限しません。エンド・ユーザーがアプリケーションをプリプロセスするとき、そのユーザーが結果のパッケージを所有します。

アプリケーション実行
DB2 (VM 版) エンド・ユーザーがリモート・アプリケーションを実行するには、特定のアプリケーションに関連したリモート・パッケージを実行するためにエンド・ユーザーにリモート・サイト (アプリケーション・サーバー) での権限がなければなりません。パッケージの作成者 (所有者) には、パッケージを実行する権限が自動的に与えられます。他のエンド・ユーザーは、 DB2 (VM 版) GRANT execute ステートメントでパッケージを実行する権限を得られます。このようにして、分散データベース・アプリケーションの所有者は個々のユーザー・ベースでアプリケーションの使用を制御できます。

機密保護サブシステム

VM システムの外部機密保護サブシステムは RACF か、 RACF と互換性のあるインターフェースを備えた同等の製品のいずれかにより提供されます。 DB2 (VM 版) アプリケーション・リクエスターは外部機密保護サブシステムと直接やり取りしません。外部機密保護サブシステムは、会話レベル機密保護のパスワードを提供するためには使用されません。セッション・レベル機密保護を使用することを選択すると、 VTAM により外部機密保護サブシステムが呼び出されてパートナー LU の検証中にリモート LU 名の ID が妥当性検査されます。

データの表示

アプリケーション・リクエスターには、適切な省略時 CHARNAME および CCSID 値がなければなりません。適切な値を選択すると、文字データ表記の保全性が確保され、 CCSID 会話に関連するパフォーマンス・オーバーヘッドを減少させます。

たとえば、ご使用の DB2 (VM 版) アプリケーション・リクエスターがコード・ページ 37 および米国英語の文字セット 697(CP/CS 37/697) で生成された場合、アプリケーション・リクエスターは省略時 CHARNAME を ENGLISH に設定しなければなりません。 CP/CS 37/697 が 37 の CCSID に対応し、これは ENGLISH の CHARNAME に対応するからです。

新しくインストールされたか移行されたシステムの省略時 CHARNAME は INTERNATIONAL であり、 CCSID は 500 です。これはおそらく、ご使用のインストール・システムでは正しくない でしょう。現行の省略時 CCSID の値を表示するには、以下のコマンドを使用してください。

SQLINIT QUERY

アプリケーション・リクエスターでは適切な CCSID でも、アプリケーション・サーバーの変換テーブルにはサポートされていない場合があります。この場合には、以下のいずれかを実行して接続を確立できます。

アプリケーション・サーバーでは適切な CCSID 値でも、アプリケーション・リクエスターの変換テーブルにはサポートされていない場合があります。この場合には、以下のいずれかを実行して接続を確立できます。

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

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

  1. ローカル AVS ゲートウェイを VTAM に定義する。
  2. ARISDBMA exec を使用して、 DRDA サポートを DB2 (VM 版) アプリケーション・リクエスターにインストールする。
  3. CMS 通信ディレクトリーを設定して、必要な APPCPASS ステートメントをアプリケーション VM マシンの VM ディレクトリーに追加する。 SET COMDIR CMS コマンドを使用して、通信ディレクトリーを使用可能にします。
  4. VTAM および AVS を始動して、 VM アプリケーションが SNA ネットワークを介してリモート通信できるようにする。
  5. SQLINIT exec を出して、DBNAME、PROTOCOL および CHARNAME パラメーターを指定します。これらのパラメーターは省略時データベース、使用しているプロトコルおよび CCSID を示しています。
  6. リモート・サーバーでアプリケーションを準備する。


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