問題判別の手引き
この節では、ユーザーがクライアントを DB2 サーバーに接続しようとする場合に、
しばしば直面する問題を処理する方法について説明しています。
以下のトピックを扱います。
詳細については、以下の資料を参照してください。
ご使用のプラットフォーム用の概説およびインストール を参照することもできます。
重要: この節では、DB2 カスタマー・サポートから利用可能な情報の簡単なサンプルを示します。
DB2 に関する完全な最新情報については、DB2 Product and Service Technical Library (URL は http://www-4.ibm.com/software/data/db2/library/) にアクセスしてください。
(この情報は英語のみですのでご注意ください。)
クライアントで発生した問題の原因を推定する場合、以下の点を確認してください。
- [ ]
- クライアントおよびサーバーは正常にインストールされている。
- [ ]
- 通信用の製品がクライアントおよびサーバーにインストールされており、
作動可能になっている。
- [ ]
- クライアントは以前は正しく機能していた。
- [ ]
- データベース管理プログラムが適切な通信 listener を持つサーバー上で開始された。
- [ ]
- DB2 ユニバーサル・データベースとは関係のない別のサーバーに、
クライアントから接続を確立できる。
ping、telnet、
または ftp などの別のコマンドまたはユーティリティーを使用すれば、接続を確立できる。
- [ ]
- サーバーに別のクライアントから接続を確立できる。
この節では、以下の方法について説明します。
- サーバーへの接続をテストする
- db2diag.log ファイルを使用して、通信 listener が使用可能になっているか検査する
クライアント接続の確立に問題がある場合は、
サーバー・マシンから接続をテストしてください。
- ローカル・データベース・ディレクトリー項目を使用して、
サーバー上にあるデータベースへの接続を試みます (IPC 接続を確立するため)。
この接続が失敗した場合、おそらくサーバーに問題があります。
- ループバック接続をテストします。
まず、ローカル・マシンを指すノードのカタログを作成します。
次に、この新しいノード上のデータベースのカタログを作成します。
最後に、そのサーバーからサーバー自身への接続を試みます。
注: | データベースのカタログ作成については、
管理の手引き: インプリメンテーション を参照してください。
|
- 接続が成功した場合、クライアントに問題があります。
接続が失敗した場合、問題は以下のいずれかです。
- サーバー上のプロトコル・スタックが作動していない
- 必須の通信プロトコル (複数の可能性あり) の listener がサーバー上で開始していない
- LAN ネットワークが作動していない
セットアップしたディレクトリー項目はサーバー上に保管しておくことをお勧めします。
そのようにすると、接続性の問題が再び発生した場合でも、
それらの問題を診断することができます。
クライアント問題の原因がサーバーであることが分かった場合、
サーバーの db2diag.log ファイルにこの問題の原因についての詳細な情報がある可能性があります。
このファイルの使用に関する詳細については、
初期障害データ捕そく機能を参照してください。
たとえば、サーバー上で db2start コマンドを出した後で、SQL5043N メッセージを受け取る場合があります。
このメッセージは、1 つまたは複数のプロトコルが正常に開始されなかったことを示しています。
db2diag.log ファイルにこの問題を診断するのに役立つ追加情報が含まれている可能性があります。
クライアントに影響を与えている可能性のあるサーバー問題の原因を探す場合、
以下のステップを実行してください。
- サーバー上で DIAGLEVEL を 4 に設定します。
db2 UPDATE DATABASE MANAGER CONFIGURATION USING DIAGLEVEL 4
db2 terminate
- サーバーに接続されたすべてのアプリケーションを切断します。
db2 force application all
- サーバーを再始動します。
db2stop
db2start
- サーバー上にある db2diag.log ファイルを調べます。
DB2COMM レジストリー値に指定されているプロトコルごとに、
プロトコル listener が正常に開始されたことを示すメッセージ、
またはプロトコル listener が失敗した理由を示すメッセージがあります。
(listener の説明については、第 14 章, DB2 プロセス・モデルを参照してください。)
プロトコルに関するメッセージがない場合、DB2 は DB2COMM レジストリー値にあるプロトコルを検出しなかったか、
またはプロトコルを開始しようとしませんでした。
プロトコル listener が開始しなかったことの理由としては、
通信プロトコルのインストール・ミスやサーバー構成の間違いなど、
いろいろなことが考えられます。
詳細については、以下の節を参照してください。
- 予期していた通信プロトコルすべてがサーバーで正常に開始している場合、
接続を再試行します。
問題を診断するための手掛かりについては、
クライアント上にある db2diag.log ファイルを調べてください。
初期接続 とは、
クライアントのインストール後に始めて試行されるリモート・サーバーへの接続のことです。
初期接続が失敗した場合、
サーバー自身からローカルにデータベースへの接続を試みてください。
その方法で接続が成功した場合は、問題はクライアントからの接続にあります。
接続できない場合、問題はサーバー上のデータベース管理プログラムにある可能性があります。
問題がある場合、以下の手順に従ってください。
- [ ]
- クライアントおよびサーバーが正常にインストールされているか確認します。
インストール中は、問題があれば画面上にメッセージが表示されます。
OS/2、Windows 95、Windows 98、および Windows NT オペレーティング・システムの場合、
次のようにして自動インストールのインストール・ログを保持することもできます。
エラー・ログ・ファイルおよびヒストリー・ファイルをそれぞれ /l1 および /l2 オプションを設定して指定します。
(インストール要求にこれらのオプションを指定しなかった場合、
これらのファイルは保持されません。)
- [ ]
- 前提条件のソフトウェア製品がすべてインストールされているか確認します。
- [ ]
- 通信用の製品がインストールされており、作動可能になっているか確認します。
- [ ]
- そのサーバーに別のクライアントから接続できるか確認します。
接続できる場合、そのサーバーは正常に機能しています。
接続できない場合、ネットワークまたはサーバーに問題がある可能性があります。
- [ ]
- そのクライアントから別のサーバーに接続できるか確認します。
接続できる場合、クライアントは正常に動作しています。
それまでサーバーに接続されていた 1 つまたは複数のクライアントで突然問題が起きた場合は、
以下の質問を検討してください。
問題が発生したクライアントは 1 つだけですか?
- [ ]
- 他のネットワーク使用可能アプリケーションは、
このクライアント上で実行できますか?
実行できない場合、おそらく問題は DB2 ではなく通信ソフトウェアにあります。
- [ ]
- 問題のクライアントに固有な操作環境が何かありますか?
サーバーに接続できる他のクライアントと比較してください。
- [ ]
- クライアントに影響を与えた可能性のある変更を最近しましたか?
(たとえば、別の製品または修正パックをインストールしましたか?)
- [ ]
- クライアント上で、リソース制限 (たとえば、メモリー) を超えていますか?
問題が発生したクライアントは複数ありますか?
- [ ]
-
LAN は使用可能ですか?
たとえば、TCP/IP 使用時に ping コマンドを使用できますか?
または、NETBIOS の使用時に net use コマンドを出せますか?
- [ ]
- サーバーは作動可能ですか?
サーバー・マシンで接続をテストしてください。
- [ ]
- 必要な通信 listener がサーバー上にありますか?
詳細については、db2diag.log ファイルを使用してサーバー通信問題を診断するを参照してください。
- [ ]
- サーバーのリソース制限 (たとえば、メモリー) を超えていますか?
- 症状
- Windows 95 または Windows 98 クライアントから DB2 にアクセスしようとすると、
ユーザー名が無効であるというメッセージを受け取ります。
(通常、SQL1403N メッセージを受け取ります。)
- 推定原因
- ユーザーまたはユーザーが使用しているアプリケーションが CONNECT ステートメントの一部としてユーザー名およびパスワードを指定していない場合、
代わりに暗黙のユーザー名およびパスワードが使用されます。
オペレーティング・システムにログオンしたときに使用したユーザー名およびパスワードが、CONNECT ステートメントに指定されて渡されます。
しかし、暗黙のユーザー名およびパスワードは正しくない場合があります。
その場合、CONNECT ステートメントが失敗します。
注: | Windows 95 および Windows 98 では、
ユーザー名およびパスワードを指定しなくてもログオンできます。
この場合、暗黙のユーザー名およびパスワードはヌル値になるため、CONNECT ステートメントは失敗します。
|
- 処置
- 接続要求の場合、
ユーザーまたはユーザー作成アプリケーションが CONNECT ステートメントの一部になるユーザー名とパスワードを提供する必要があります。
CONNECT TO database USER userid USING password
- サーバーのデータベース管理プログラム構成で認証 が SERVER に設定されている場合、
サーバー上で有効なユーザー名とパスワードを提供しなければなりません。
これがデフォルトです。
- サーバーのデータベース管理プログラム構成で認証 が CLIENT に設定されている場合、
クライアント上で有効なユーザー名とパスワードを提供しなければなりません。
DB2 ユニバーサル・データベース (Windows 版) 概説およびインストール を参照してください。
この節では、TCP/IP に関連する共通した問題判別のヒントを概説します。
- 症状
- TCP/IP を使用してクライアントからデータベースに接続しようとして、接続が失敗した場合、
メッセージ SQL30081N を、プロトコル固有のエラー・コード ECONNREFUSED (Intel ベースのマシン上では "10061"、
UNIX ベースの環境では "79" の場合もある) とともに受け取ることがよくあります。
- 推定原因
- このエラー・コードは、クライアント接続が拒否されたことを示します。
(SQL30081N のその他のエラー・コードについては、メッセージ解説書 を参照してください。)
- 処置
- 以下のことを確認してください。
- [ ]
- db2start が出され、TCP/IP listener がサーバー上で開始されている。
詳細については、db2diag.log ファイルを使用してサーバー通信問題を診断するを参照してください。
- [ ]
- TCP/IP スタックが、クライアントとサーバーの両方で機能している。
TCP/IP プロトコルのテスターである pctt を使用して、
プロトコルがネットワーク上で稼働しているか検査できます。
このテスターは、sqllib ディレクトリーの bin サブディレクトリー内にあります。
または、クライアントから、ping コマンドにサーバーのホスト名を指定して実行してください。
- [ ]
- ディレクトリーが正しくカタログ化されている。
特に、以下のことを確認してください。
ディレクトリー項目を検査および変更するには、以下のものを使用します。
- クライアント構成アシスタント
- CATALOG DATABASE および CATALOG TCPIP NODE コマンド。
詳細については、コマンド解説書 を参照してください。
- [ ]
- TCP/IP サービス・ファイルが壊れていない。
特にテキスト・エディターを使用して更新した場合。
ファイルの終わりにポート設定の行を追加した場合、
その次にブランク行がなければなりません。
- [ ]
- 使用されているポート番号が、
クライアントとサーバー・インスタンスのそれぞれの TCP/IP サービス・ファイルで同じである。
ポート番号は TCP/IP サービス・ファイル内で固有に定義されています。
- 症状
- サーバー上で SQL5043N メッセージを受け取ります。
- 推定原因
-
- TCP/IP がサーバー・マシン上で始動していません。
- データベース管理プログラム構成が正しくありません。 (たとえば、
定義されている svcename 構成パラメーターが正しくない。)
- TCP/IP サービス・ファイルが正しくありません。
(たとえば、
データベース管理プログラム構成の svcename 構成パラメーターがファイル内に定義されていない。)
- 処置
- サーバー上にある db2diag.log を表示します。
さらに詳しい情報を提供しているメッセージを探します。
- 症状
- リモート DB2 サーバーにアクセスしているクライアント・アプリケーションが中断しているように見えます。
- 推定原因
- サーバーがダウンしていることが、クライアントに通知されませんでした。
TCP/IP プロトコルの特性のため、
あるホスト上の TCP/IP サブシステムが別のホスト上にあるパートナーの障害について通知されない場合があります。
DB2 は、TCP/IP の接続 KEEPALIVE オプションを使用して、
接続障害があるかどうかを検出します。
このオプションは、
パートナーがまだ活動状態にあるかどうかを判別するために周期的にメッセージを送信します。
パートナーがこのメッセージに応答しないと、
接続は失敗したとみなされ、エラーが戻されます。
クライアントの KEEPALIVE 設定値で TCP/IP 接続の検査間隔が頻繁ではない値に設定され、
かつサーバーがダウンしている場合、クライアントが中断しているように見えることがあります。
- 処置
- サーバーで中断しているエージェント・プロセスを除去するには、FORCE APPLICATION コマンドを使用します。
問題が解決しない場合には、KEEPALIVE 設定値の値を変更し、
接続障害を検出するためにメッセージを送信する時間間隔を変更してください。
注: | KEEPALIVE 設定値は、
マシン上で実行している TCP/IP アプリケーションすべてに影響を与えます。
|
- Windows 95、Windows 98、および Windows NT の場合:
レジストリーの KeepAliveTime TCP/IP 構成パラメーターを使用します。
KEEPALIVE パラメーターは、パラメーター・レジストリー・サブキーの下に存在しない場合に作成されることがあります。
このパラメーターを以下のものに追加してください。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
デフォルトは 2 時間です。
- OS/2 の場合:
inetcfg コマンドを使用します。
(OS/2 TCP/IP バージョン 2.0 の場合、
このコマンドを使用するには修正 CSD UN64092 を適用しなければなりません。)
- AIX の場合:
no コマンドを使用して、
ネットワーク・オプションの値 tcp_keepidle および tcp_keepintvl を変更します (詳細については、
man no と入力してください)。
デフォルトは 2 時間です。
- HP-UX システムの場合:
nettune コマンドを使用して、
ネットワーク・オプションの値 tcp_keepstart および tcp_keepfreq を変更します (詳細については、
man nettune と入力してください)。
- Solaris システムの場合:
次のコマンドを使用して、
ネットワーク・オプション tcp_keepalive_interval の値を変更します。
ndd -set /dev/tcp tcp_keepalive_interval value
(詳細については、man ndd と入力してください。)
- SINIX システムの場合:
以下のコマンドを使用して、
ネットワーク・オプションの値 TCPTV_KEEP_IDLE_SECS および TCPTV_KEEPINTVL_SECS を変更します。
/etc/conf/bin/idtune TCPTV_KEEP_IDLE_SECS value
/etc/conf/bin/idtune TCPTV_KEEPINTVL_SECS value
(詳細については、man idtune と入力してください。)
デフォルトは 2 時間 10 分です。
- その他のプラットフォームの場合:
KEEPALIVE 設定値の構成の詳細については、TCP/IP 文書を参照してください。
TCP/IP スタックによってサポートされていない場合、DB2 では使用されていません。
この節では、IPX/SPX 通信プロトコルでの問題判別のヒントを扱います。
- 症状
-
DB2 サーバーに接続しようとすると、SQL30081N メッセージを受け取ります。
- 処置
- 以下のことを確認してください。
- [ ]
-
Novell Netware TLI*.DLL ファイルが正しいレベルである。
(DB2 または Novell の Web サイトにアクセスして、最新の Novell Netware 修正情報を検索してください。)
- [ ]
- ファイル・サーバー・アドレッシング・モードを使用している場合、
クライアントのノード・ディレクトリー項目にあるファイル・サーバー名とオブジェクト名が、
サーバー上のデータベース管理プログラム構成ファイルの fileserver と objectname の値と一致している。
これらの名前は同じでなければならず、かつ両方とも英大文字でなければなりません。
- [ ]
-
ファイル・サーバー・アドレッシング・モードを使用している場合、DB2 のインストールおよび構成後にデータベース・サーバーをファイル・サーバー上で登録した。
REGISTER コマンドの詳細については、コマンド解説書 を参照してください。
- [ ]
- サーバー・マシンがネットワーク上で移動し、
かつそのマシンの IPX/SPX インターネットワーク・アドレスが変わった場合、DB2 サーバーのインターネットワーク・アドレスを変更前に登録解除し、
変更後に再登録した。
- [ ]
- ファイル・サーバー・アドレッシング・モードを使用してデータベースに接続している場合、DB2 サーバー・インスタンスを表す (つまり、
サーバー・インスタンスの IP アドレスを保管する) オブジェクト名はファイル・サーバーのバインダリーにある。
- [ ]
- 直接アドレッシング・モードを使用している場合、
以下の値がクライアントのノード・ディレクトリーにある。
- 症状
- OS/2 の場合、SQL30081N メッセージを、関数 t_open および理由コード 8 とともに受け取ります。
- 推定原因
-
- NetWare 製品が正しくインストールされていないか、
正しく構成されていないか、または破壊されているために、
正常に機能しません。
- 要求を処理するための十分なシステム・リソースがありません。
- 処置
-
以下のことを確認してください。
- [ ]
-
DOS および Windows の場合、
クライアント上にある net.cfg ファイルの最初の 2 行は、以下のようになっているか。
ECB COUNT=50
DATA ECB COUNT=89
net.cfg ファイルは、ルート・ディレクトリーにあります。
- [ ]
-
OS/2 CONFIG.SYS ファイルの FILES パラメーターが適切なレベルに設定されている。
このパラメーターが、DOS および Win-OS/2 セッション内で実行中のすべてのプログラムによって使用可能なファイルの最大数を決めます。
- [ ]
-
OS/2 の場合、AUTOEXEC.BAT ファイルのパスに OS/2 NETWARE ディレクトリーが含まれていない。
このパスは DOS、
Windows、および OS/2 環境のためのもので、
OS/2 NETWARE ディレクトリーの DLL ファイルは OS/2 DLL ファイルです。
Windows DLL ファイルと OS/2 NetWare DLL ファイルとは名前は同じであることもありますが、DOS および Windows で OS/2 DLL をロードまたは実行することはできません。
- 症状
- これまでは成功していた接続が、DB2 (OS/2 版) サーバーへの IPX/SPX 接続でハングします。
- 推定原因
- NetWare リソースに問題がある可能性があります。
- 処置
-
十分な数の接続リソースを提供したといえるようにするには、net.cfg ファイルが以下のように設定されているかどうかを確認してください。
- protocol stack ipx サブセクションに 128 ソケット
- protocol stack spx サブセクションに 50 セッション
これらの構成パラメーターの詳細については、IPX/SPX 資料を参照してください。
net.cfg ファイルは、通常はルート・ディレクトリーにあります。
このファイルは、OS/2 では NETWARE ディレクトリーにある場合もあります。
システム・ブートアップ画面を検査して、net.cfg ファイルが使用されているかを判別してください。
- 症状
- Windows または OS/2 クライアントから接続しようとすると、SQL1109N エラー・メッセージを受け取ります。
- 推定原因
-
NWCALLS.DLL ファイルおよび TLI_SPX.DLL ファイルの 2 つのバージョンがあります。
1 つは OS/2 用、もう 1 つは Windows 用です。
これらのファイルのある場所が正しくない可能性があります。
- 処置
- Novell の NWDLL2.exe パッケージからの NWCALLS.DLL は WINDOWS\SYSTEM ディレクトリーになければなりません。
Windows が OS/2 用の NWCALLS.DLL をロードしないようにしてください。
- 症状
- サーバー上で SQL5043N メッセージを受け取ります。
- 推定原因
-
- IPX/SPX がサーバー・マシン上で始動していません。
- データベース管理プログラム構成が正しくありません。
(たとえば、fileserver、
objectname、または ipx_socket パラメーターが正しくない。)
- 処置
- サーバー上にある db2diag.log ファイルを表示します。
さらに詳しい情報を提供しているメッセージを探します。
この節では、NetBIOS 通信プロトコルに関連する問題判別のヒントを扱います。
NetBIOS は UNIX ベースの環境では使用されません。
- 症状
- クライアントからサーバーに接続できない場合、
普通は SQL30081N メッセージを戻りコード 0x14 とともに受け取ります。
- 処置
- 次のチェックリストを使用して、問題を診断してください。
ディレクトリー・キャッシュを使用していて、
データベースまたはノード・ディレクトリーを変更する場合、
変更が有効になるようにクライアントで TERMINATE コマンドを使用しなければなりません。
- [ ]
- NetBIOS listener がサーバー上で始動していますか?
db2diag.log ファイル内の NetBIOS リソースを検査して、
問題があるかどうかを確かめてください。
詳細については、NetBIOS 用のサーバーで SQL5043N を受け取ったを参照してください。
- [ ]
- クライアントおよびサーバーが NetBIOS サポートを始動するように設定されていますか?
NetBIOS は、サーバーの構成とクライアントの構成の両方に含まれていなければなりません。
- [ ]
-
クライアント上でノードをカタログ化したときに、
正しいアダプター番号を指定しましたか?
クライアントのノード・ディレクトリーに指定されているアダプターを確かめてください。
このアダプター番号は、
クライアントで NetBIOS 通信のために構成されているアダプターと一致していなければなりません。
通常、アダプター番号は 0 です。ただし、複数のアダプターが構成されている場合、
クライアントによって使用されているアダプターがサーバーに到達できる LAN 用になるようにしなければなりません。
Windows NT 上でネイティブの NetBIOS を使用している場合、
アダプター番号は論理 LAN アダプター番号 (Lana 番号) と呼びます。
この値を検査するには、以下の手順に従ってください。
- 「コントロール パネル」から「ネットワーク」アイコンを選択します。
- 「サービス」タブから、NetBIOS インターフェースを選択します。
- 「プロパティ」を選択します。
- ネットワーク経路 Nbf に関連付けられた Lana 番号は、
ノードをカタログ化した方法と一致していなければなりません。
- [ ]
- ゲートウェイ、ブリッジ、ルーター、
または LAN ケーブルで LAN 層の物理的な問題がありますか?
- [ ]
- サーバーの LAN をクライアントの LAN に接続するブリッジまたはルーター上で、
名前フィルター操作が行われていますか?
LAN ブリッジまたはルーターが DB2 の名前構造に基づく名前を無視しているために、
クライアント要求が異なる LAN 上にあるサーバーに到達できなくなっている可能性があります。
この可能性について、LAN 管理者と相談してください。
- [ ]
- サーバーとクライアントは互換性のある NetBIOS スタックを使用していますか?
サーバーとそのクライアントは、ネイティブの NetBIOS または同一の NetBIOS エミュレーションを使用するようにしてください。
NetBIOS プロトコルのテスターである pctn を使用して、
プロトコルがネットワーク上で稼働しているかが検査できます。
このテスターは、sqllib ディレクトリーの bin サブディレクトリー内にあります。
- 症状
-
サーバーにクライアントを正常に接続することができたのに、接続が突然終了してしまいます。
その際、通常は SQL30081N メッセージが表示され、db2diag.log ファイルには戻りコード 0x08 または 0x18 が記録されます。
- 推定原因
- NetBIOS プロトコルが DB2 サーバーにタイムアウトを報告しています。
おそらく、LAN に物理的な問題があるためです。
この問題は、OS/2 システム上で時折起こります。
- 処置
- NetBIOS サービス担当者にその状態を報告し、
Web 上の DB2 Product and Service Technical Library (URL は http://www-4.ibm.com/software/data/db2/library/) にアクセスして、
修正方法があるどうか確認します。
(この情報は英語のみですのでご注意ください。)
- 症状
- サーバー上で SQL5043N メッセージを受け取ります。
- 推定原因
- NetBIOS listener が始動していません。
- 処置
- サーバー上にある db2diag.log ファイルを表示します。
以下の項目を探してください。
- [ ]
-
DIA3426C:
- データベース管理プログラム構成を有効な nname で更新し、
インスタンスを停止してから開始します。
- [ ]
- DIA3409I または DIA3420C:
- 症状
- ワークグループ環境では、名前付きパイプを使用してデータベース・サーバーにアクセスしようとしているユーザーは、
SQL30082N メッセージを理由コード 18 (名前付きパイプ・アクセスが否認された) とともに受け取ります。
- 推定原因
- リモート・サーバーで名前付きパイプにアクセスする前に、
システム・レベルのオープン・セッションがなければなりません。
この場合、ユーザー認証がサーバーで失敗しました。
したがって、セッションはヌル値セッションであり、
名前付きパイプにアクセスするための認証を持っていません。
- 処置
- 以下のいずれかを行ってください。
- リモート・サーバー上でクライアントのユーザー名とパスワードを作成する。
- リモート・サーバーにあるゲスト・アカウントを使用可能にする。
- リモート・サーバーのネットワーク・リソースを共用する。
たとえば、net use を実行して、
サーバーのネットワーク・ドライブにアクセスします。そこで、
リモート・サーバーで有効なユーザー名とパスワードを使用することができます。
APPC 接続に問題が生じた場合には、以下のチェックリストを検討してください。
- [ ]
- クライアントまたはサーバーのインストールの際に、
概説およびインストール にある指示に従いましたか?
この資料は、APPC 構成の手順を段階的に説明しています。
- [ ]
- VTAM を使用している場合、サーバーおよびクライアントに正しい論理装置 (LU) 名が定義されていますか?
- [ ]
- 正しい TP 名が定義されていますか?
- [ ]
- SNA を使用している場合、正しい SNA ノード ID が定義されていますか?
- [ ]
- DB2 ノード・ディレクトリーで適切な APPC セキュリティーを、
また DB2 データベース・ディレクトリーで適切な DB2 認証を使用していますか?
ともに使用できる認証とセキュリティーのタイプの詳細については、
概説およびインストール を参照してください。
DB2 ノード・ディレクトリー内にあるセキュリティー設定が SNA セキュリティー構成を一時変更することに注意してください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]