DB2 (VM 版) のアプリケーション・サポートによって、 DB2 (VM 版) は DRDA アプリケーション・リクエスターのサーバーとして機能することができます。 DB2 (VM 版) アプリケーション・サーバーに接続されているアプリケーション・リクエスターは以下のいずれかです。
DB2 (VM 版) アプリケーション・サーバーに接続しているアプリケーション・リクエスターでは、 DB2 (VM 版) アプリケーション・サーバーによって、 DB2 (VM 版) アプリケーション・サーバーにローカルで保管されているデータベース・オブジェクト (表など) にアクセスできます。アプリケーション・リクエスターは、接続が確立される前に、アプリケーションの SQL ステートメントが含まれるパッケージを、 DB2 (VM 版) アプリケーション・サーバーに作成しなければなりません。
DB2 (VM 版) アプリケーション・サーバーが分散データベース要求を処理するためには、以下のステップを行ってください。
アプリケーション・サーバーが分散データベース要求を受信するためには、アプリケーション・サーバーをローカル通信サブシステムに定義し、固有の RDB_NAME 名を割り当てます。
以下のステップを実行して、アプリケーション・サーバーを定義してください。
NETID は始動パラメーターとして VTAM に定義されており、アプリケーション・リクエスターからのすべての分散要求は正確にこのパラメーターに経路指定されます。 DB2 (VM 版) アプリケーション・サーバーは NETID を設定しません。
DB2 (VM 版) アプリケーション・サーバーは、アプリケーション・リクエスターからのインバウンド分散要求を経路指定するゲートウェイを判別しません。アプリケーション・リクエスターが常にそれを制御します。 DB2 (VM 版) アプリケーション・リクエスターの場合、CMS 通信ディレクトリーが :luname および :tpn タグを使用してそれを指定します。
DB2 (VM 版) アプリケーション・サーバーが分散作業単位活動をサポートするために、アプリケーション・リクエスターは、 SYNCLVL=SYNCPT パラメーターを使用して VTAM に定義されている AVS ゲートウェイを選択していなければなりません。必ず AVS ゲートウェイを定義して、分散作業単位をサポートするようにしてください。
RU サイズ、セッション限度、および歩調合わせカウントを選択した後は、 VTAM IOBUF プールに与えるこれらの値の影響を考慮してください。
資源 ID (RESID) は、トランザクション・プログラム名の VM 用語です。 VM 環境では、これは一般に 8 バイト以下の長さの英数字名で定義されます。管理を簡潔にするために、通常は 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 版) アプリケーション・サーバーが、 DRDA サポートをインストールしていない場合があります。以下のステップに従って、 DRDA 通信用に DB2 (VM 版) アプリケーション・サーバーを準備します。
詳細については、 VM/ESA System Administration を参照してください。
アプリケーション・リクエスターが分散データベース要求を 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 に授与された特権を使用しないようにします。
これらの処置はモントリオールのシステムでも実行でき、トロントの 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 版) でプリプロセスされるときは、パッケージにはアプリケーション・プログラムにある SQL ステートメントが含まれています。これらの SQL ステートメントは以下のように分けられます。
エンド・ユーザーがパッケージを実行する特権を与えられるとき、そのエンド・ユーザーはパッケージに含まれる各静的 SQL ステートメントを実行する権限を自動的に持ちます。それで、パッケージに静的 SQL ステートメントしか含まれていない場合には、エンド・ユーザーには DB2 (VM 版) 表特権の必要はありません。
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 つの目標が対立する場合の例を次に示します。
アプリケーション・サーバーの省略時 CHARNAME が ENGLISH に設定されている場合には、これによりローカル・アプリケーション・リクエスターのデータ保全性が保持されますが、 CCSID 変換オーバーヘッドがすべてのリモート・アプリケーション・リクエスターに及びます。
アプリケーション・サーバー省略時 CHARNAME が UK-ENGLISH に設定されている場合、すべてのリモート・アプリケーション・リクエスターが CCSID 変換オーバーヘッドによって損害を受けることを避けることができます。しかし、ローカル・アプリケーション・リクエスターでデータ保全性の問題 (ある文字がローカル・アプリケーション・リクエスターで表示されない) が生じます。たとえば、英国ポンド記号はドル記号として表示されます。
システムの現行の 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 です。
以下のチェックリストは DRDA 通信用の DRDA アプリケーション・サーバーを使用可能にするためのステップを要約したものですが、初めに次のような前提事項があります。まず、 VM システムがテレプロセシング・アクセス方式として ACF/VTAM を使用してインストールされていること、そして、リモート・システムとの通信に必要な VTAM 定義 (NCP 定義など) がすでに完了していることです。