DB2 (MVS/ESA 版) のアプリケーション・サーバー・サポートによって、 DB2 (MVS/ESA 版) は DRDA アプリケーション・リクエスターのサーバーとして機能することができます。 DB2 (MVS/ESA 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターは、以下のものとして機能することができます。
DB2 (MVS/ESA 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターの場合、 DB2 (MVS/ESA 版) アプリケーション・サーバーは以下のようにデータベース・アクセスをサポートします。
DB2 (MVS/ESA 版) アプリケーション・サーバーが適正に分散データベース要求を処理するためには、次のステップを踏む必要があります。
アプリケーション・サーバーが分散データベース要求を受信するためには、これをローカルなコミュニケーション・マネージャーに定義し、固有の RDB_NAME 名を割り当てる必要があります。アプリケーション・サーバーを正しく定義するには、次のステップを踏む必要があります。
VTAM ネットワークを調べる方法については、 RU サイズおよび歩調合わせの設定を参照してください。
たとえば、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', ' '); |
図 11 では、LUNAME 列にブランクの行はないため、 DB2 (MVS/ESA 版) は LUDALLAS または LUNYC 以外の LU へのアクセスをすべて拒否します。
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', ' '); |
DB2 (MVS/ESA 版) では、DRDA に定義したデータベース・サーバーを実装していません。その代わり、DB2 (MVS/ESA 版) では 2 次サーバーを使用できます。これは、システム主導アクセスを使って単一の作業単位の範囲で複数の DB2 (MVS/ESA 版) システムにアクセスすることを可能にします。
システム主導アクセスで主導サポートされる SQL は、 DRDA リモート作業単位の場合と大いに異なります。
SELECT * FROM CHICAGO.USER.TABLE;
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 オブジェクト名の解決
![]() |
DB2 (MVS/ESA 版) アプリケーション・サーバーが SQL を再経路指定する場合、 CDB および VTAM に各 2 次サーバーを定義する必要があります。定義のプロセスは、リモート・システムの定義に説明されているプロセスとよく似ています。 2 次サーバーを接続するには、次の手順に従ってください。
データベース資源の所有者として、 2 次サーバーはそこにある SQL オブジェクトのデータベース機密保護を制御します。ただしこの責任は、要求を出す DB2 (MVS/ESA 版) アプリケーション・サーバーと共有されます。サーバーは SQL オブジェクトに対するアクセスを次のように制御します。
アプリケーション・リクエスターが分散データベース要求を DB2 (MVS/ESA 版) アプリケーション・サーバーに向けるときには、以下の機密保護上の考慮事項が関係します。
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 つと一致しなければなりません。
行が検出されない場合、リモート・アクセスは拒否されます。行が検出されると、リモート・アクセスが許可され、エンド・ユーザー名は NEWAUTHID 列で与えられた値に変換されます。 NEWAUTHID 値がブランクの場合は名前が変更されないことを示します。任意の DB2 (MVS/ESA 版) 資源に対する許可の検査 (たとえば、SQL 表特権) が、DB2 (MVS/ESA 版) により、元のユーザー名ではなく変換されたエンド・ユーザー名に対して実行されます。
DB2 (MVS/ESA 版) アプリケーション・サーバーがアプリケーション・リクエスターからエンド・ユーザー名を受け取る場合、 DB2 (MVS/ESA 版) インバウンド名前変換機能を使用することによって以下のいくつかの目的が達成されます。
INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');
INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'SMITH', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES (' ', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUCHI', ' ', ' ');
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 つの基本的なオブジェクトのクラスは以下のとおりです。
アプリケーションが DB2 (MVS/ESA 版) にバインドされるとき、パッケージにはアプリケーション・プログラムに含まれる SQL ステートメントが含まれています。これらの SQL ステートメントは以下のように分けられます。
エンド・ユーザーがパッケージを実行する権限を与えられるとき、そのユーザーはパッケージに含まれる各静的 SQL ステートメントを実行する権限を自動的に与えられます。それで、実行されるパッケージに静的 SQL ステートメントしか含まれていない場合には、エンド・ユーザーは DB2 (MVS/ESA 版) 表特権を必要としません。
パッケージを作成するとき、 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 表でインバウンド名前変換機能をどのように定義したかに応じて異なります。
アプリケーション・リクエスターからの要求にユーザー ID (SECURITY=SAME) だけが含まれる場合、外部機密保護システムはまったく呼び出されません。インバウンド名前変換の規則によって、どのユーザーにDB2 (MVS/ESA 版) アプリケーション・サーバーへの接続が許可されているかが定義されているからです。
ご使用の DB2 (MVS/ESA 版) サブシステムが、各アプリケーション・リクエスターの CCSID を DB2 (MVS/ESA 版) サブシステムのインストール・システムの CCSID に変換できるかどうか確認する必要があります。詳細については、データの表示を参照してください。