問題判別の手引き

問題判別のヒント

この節では、ユーザーがクライアントを DB2 サーバーに接続しようとする場合に、 しばしば直面する問題を処理する方法について説明しています。 以下のトピックを扱います。

詳細については、以下の資料を参照してください。

ご使用のプラットフォーム用の概説およびインストール を参照することもできます。

重要: この節では、DB2 カスタマー・サポートから利用可能な情報の簡単なサンプルを示します。 DB2 に関する完全な最新情報については、DB2 Product and Service Technical Library (URL は http://www-4.ibm.com/software/data/db2/library/) にアクセスしてください。 (この情報は英語のみですのでご注意ください。)

クライアント問題の範囲を判別する

クライアントで発生した問題の原因を推定する場合、以下の点を確認してください。

[ ]
クライアントおよびサーバーは正常にインストールされている。

[ ]
通信用の製品がクライアントおよびサーバーにインストールされており、 作動可能になっている。

[ ]
クライアントは以前は正しく機能していた。

[ ]
データベース管理プログラムが適切な通信 listener を持つサーバー上で開始された。

[ ]
DB2 ユニバーサル・データベースとは関係のない別のサーバーに、 クライアントから接続を確立できる。 pingtelnet、 または ftp などの別のコマンドまたはユーティリティーを使用すれば、接続を確立できる。

[ ]
サーバーに別のクライアントから接続を確立できる。

この節では、以下の方法について説明します。

サーバー上で接続をテストする

クライアント接続の確立に問題がある場合は、 サーバー・マシンから接続をテストしてください。

  1. ローカル・データベース・ディレクトリー項目を使用して、 サーバー上にあるデータベースへの接続を試みます (IPC 接続を確立するため)。 この接続が失敗した場合、おそらくサーバーに問題があります。
  2. ループバック接続をテストします。 まず、ローカル・マシンを指すノードのカタログを作成します。 次に、この新しいノード上のデータベースのカタログを作成します。 最後に、そのサーバーからサーバー自身への接続を試みます。

    注:データベースのカタログ作成については、 管理の手引き: インプリメンテーション を参照してください。

  3. 接続が成功した場合、クライアントに問題があります。 接続が失敗した場合、問題は以下のいずれかです。

セットアップしたディレクトリー項目はサーバー上に保管しておくことをお勧めします。 そのようにすると、接続性の問題が再び発生した場合でも、 それらの問題を診断することができます。

db2diag.log ファイルを使用してサーバー通信問題を診断する

クライアント問題の原因がサーバーであることが分かった場合、 サーバーの db2diag.log ファイルにこの問題の原因についての詳細な情報がある可能性があります。 このファイルの使用に関する詳細については、 初期障害データ捕そく機能を参照してください。

たとえば、サーバー上で db2start コマンドを出した後で、SQL5043N メッセージを受け取る場合があります。 このメッセージは、1 つまたは複数のプロトコルが正常に開始されなかったことを示しています。 db2diag.log ファイルにこの問題を診断するのに役立つ追加情報が含まれている可能性があります。

クライアントに影響を与えている可能性のあるサーバー問題の原因を探す場合、 以下のステップを実行してください。

  1. サーバー上で DIAGLEVEL を 4 に設定します。

    db2 UPDATE DATABASE MANAGER CONFIGURATION USING DIAGLEVEL 4
    db2 terminate
    
  2. サーバーに接続されたすべてのアプリケーションを切断します。

    db2 force application all
    
  3. サーバーを再始動します。

    db2stop
    db2start
    
  4. サーバー上にある db2diag.log ファイルを調べます。

    DB2COMM レジストリー値に指定されているプロトコルごとに、 プロトコル listener が正常に開始されたことを示すメッセージ、 またはプロトコル listener が失敗した理由を示すメッセージがあります。 (listener の説明については、第 14 章, DB2 プロセス・モデルを参照してください。)

    プロトコルに関するメッセージがない場合、DB2 は DB2COMM レジストリー値にあるプロトコルを検出しなかったか、 またはプロトコルを開始しようとしませんでした。

    プロトコル listener が開始しなかったことの理由としては、 通信プロトコルのインストール・ミスやサーバー構成の間違いなど、 いろいろなことが考えられます。 詳細については、以下の節を参照してください。

  5. 予期していた通信プロトコルすべてがサーバーで正常に開始している場合、 接続を再試行します。 問題を診断するための手掛かりについては、 クライアント上にある 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 上で無効

症状
Windows 95 または Windows 98 クライアントから DB2 にアクセスしようとすると、 ユーザー名が無効であるというメッセージを受け取ります。 (通常、SQL1403N メッセージを受け取ります。)

推定原因
ユーザーまたはユーザーが使用しているアプリケーションが CONNECT ステートメントの一部としてユーザー名およびパスワードを指定していない場合、 代わりに暗黙のユーザー名およびパスワードが使用されます。 オペレーティング・システムにログオンしたときに使用したユーザー名およびパスワードが、CONNECT ステートメントに指定されて渡されます。 しかし、暗黙のユーザー名およびパスワードは正しくない場合があります。 その場合、CONNECT ステートメントが失敗します。

注:Windows 95 および Windows 98 では、 ユーザー名およびパスワードを指定しなくてもログオンできます。 この場合、暗黙のユーザー名およびパスワードはヌル値になるため、CONNECT ステートメントは失敗します。

処置
接続要求の場合、 ユーザーまたはユーザー作成アプリケーションが CONNECT ステートメントの一部になるユーザー名とパスワードを提供する必要があります。

CONNECT TO database USER userid USING password

DB2 ユニバーサル・データベース (Windows 版) 概説およびインストール を参照してください。

TCP/IP の問題

この節では、TCP/IP に関連する共通した問題判別のヒントを概説します。

SQL30081N を受け取った

症状
TCP/IP を使用してクライアントからデータベースに接続しようとして、接続が失敗した場合、 メッセージ SQL30081N を、プロトコル固有のエラー・コード ECONNREFUSED (Intel ベースのマシン上では "10061"、 UNIX ベースの環境では "79" の場合もある) とともに受け取ることがよくあります。

推定原因
このエラー・コードは、クライアント接続が拒否されたことを示します。 (SQL30081N のその他のエラー・コードについては、メッセージ解説書 を参照してください。)

処置
以下のことを確認してください。

[ ]
db2start が出され、TCP/IP listener がサーバー上で開始されている。 詳細については、db2diag.log ファイルを使用してサーバー通信問題を診断するを参照してください。

[ ]
TCP/IP スタックが、クライアントとサーバーの両方で機能している。

TCP/IP プロトコルのテスターである pctt を使用して、 プロトコルがネットワーク上で稼働しているか検査できます。 このテスターは、sqllib ディレクトリーの bin サブディレクトリー内にあります。

または、クライアントから、ping コマンドにサーバーのホスト名を指定して実行してください。

[ ]
ディレクトリーが正しくカタログ化されている。 特に、以下のことを確認してください。
  • データベース・ディレクトリー項目が、正しいノード・ディレクトリー項目を示している。
  • ノード・ディレクトリー内の svcename フィールドにあるサービス名またはポート名が、 サーバーのデータベース管理プログラム構成内の svcename と同じポート番号にマップする。

    サービス名以外の利用可能なポート番号として svcename を指定することによって、 ノードをカタログ化してみてください。

  • ノード・ディレクトリーの hostname フィールド内に指定されている IP アドレスまたはホスト名が正しい。 (この項目を検査するには、ping コマンドを使用してホスト名または IP アドレスをテストします。)

ディレクトリー項目を検査および変更するには、以下のものを使用します。

  • クライアント構成アシスタント
  • CATALOG DATABASE および CATALOG TCPIP NODE コマンド。 詳細については、コマンド解説書 を参照してください。

[ ]
TCP/IP サービス・ファイルが壊れていない。 特にテキスト・エディターを使用して更新した場合。

ファイルの終わりにポート設定の行を追加した場合、 その次にブランク行がなければなりません。

[ ]
使用されているポート番号が、 クライアントとサーバー・インスタンスのそれぞれの TCP/IP サービス・ファイルで同じである。 ポート番号は TCP/IP サービス・ファイル内で固有に定義されています。

TCP/IP 用のサーバーで SQL5043N を受け取った

症状
サーバー上で SQL5043N メッセージを受け取ります。

推定原因

処置
サーバー上にある db2diag.log を表示します。 さらに詳しい情報を提供しているメッセージを探します。

クライアント・アプリケーションまたは照会が中断しているように見える

症状
リモート DB2 サーバーにアクセスしているクライアント・アプリケーションが中断しているように見えます。

推定原因
サーバーがダウンしていることが、クライアントに通知されませんでした。

TCP/IP プロトコルの特性のため、 あるホスト上の TCP/IP サブシステムが別のホスト上にあるパートナーの障害について通知されない場合があります。

DB2 は、TCP/IP の接続 KEEPALIVE オプションを使用して、 接続障害があるかどうかを検出します。 このオプションは、 パートナーがまだ活動状態にあるかどうかを判別するために周期的にメッセージを送信します。 パートナーがこのメッセージに応答しないと、 接続は失敗したとみなされ、エラーが戻されます。

クライアントの KEEPALIVE 設定値で TCP/IP 接続の検査間隔が頻繁ではない値に設定され、 かつサーバーがダウンしている場合、クライアントが中断しているように見えることがあります。

処置
サーバーで中断しているエージェント・プロセスを除去するには、FORCE APPLICATION コマンドを使用します。

問題が解決しない場合には、KEEPALIVE 設定値の値を変更し、 接続障害を検出するためにメッセージを送信する時間間隔を変更してください。
注:KEEPALIVE 設定値は、 マシン上で実行している TCP/IP アプリケーションすべてに影響を与えます。

IPX/SPX の問題

この節では、IPX/SPX 通信プロトコルでの問題判別のヒントを扱います。

SQL30081N を受け取った

症状
DB2 サーバーに接続しようとすると、SQL30081N メッセージを受け取ります。

処置
以下のことを確認してください。

[ ]
Novell Netware TLI*.DLL ファイルが正しいレベルである。 (DB2 または Novell の Web サイトにアクセスして、最新の Novell Netware 修正情報を検索してください。)

[ ]
ファイル・サーバー・アドレッシング・モードを使用している場合、 クライアントのノード・ディレクトリー項目にあるファイル・サーバー名とオブジェクト名が、 サーバー上のデータベース管理プログラム構成ファイルの fileserverobjectname の値と一致している。 これらの名前は同じでなければならず、かつ両方とも英大文字でなければなりません。

[ ]
ファイル・サーバー・アドレッシング・モードを使用している場合、DB2 のインストールおよび構成後にデータベース・サーバーをファイル・サーバー上で登録した。 REGISTER コマンドの詳細については、コマンド解説書 を参照してください。

[ ]
サーバー・マシンがネットワーク上で移動し、 かつそのマシンの IPX/SPX インターネットワーク・アドレスが変わった場合、DB2 サーバーのインターネットワーク・アドレスを変更前に登録解除し、 変更後に再登録した。

[ ]
ファイル・サーバー・アドレッシング・モードを使用してデータベースに接続している場合、DB2 サーバー・インスタンスを表す (つまり、 サーバー・インスタンスの IP アドレスを保管する) オブジェクト名はファイル・サーバーのバインダリーにある。

[ ]
直接アドレッシング・モードを使用している場合、 以下の値がクライアントのノード・ディレクトリーにある。
  • ファイル・サーバー項目はアスタリスク (*) として指定される。
  • objectname の値は、 サーバーの IPX/SPX インターネットワーク・アドレスである。

    サーバー上で db2ipxad を発行して、 サーバーの IPX/SPX インターネットワーク・アドレスを獲得してください。 このコマンドは、sqllib ディレクトリーの bin サブディレクトリー内にあります。

    同じ場所で、IPX/SPX プロトコルのテスターである pcti を使用して、 プロトコルがネットワーク上で稼働しているかを検査できます。

OS/2 での SQL30081N

症状
OS/2 の場合、SQL30081N メッセージを、関数 t_open および理由コード 8 とともに受け取ります。

推定原因

処置

以下のことを確認してください。

[ ]
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 をロードまたは実行することはできません。

OS/2 サーバーへの接続が突然ハングする

症状
これまでは成功していた接続が、DB2 (OS/2 版) サーバーへの IPX/SPX 接続でハングします。

推定原因
NetWare リソースに問題がある可能性があります。

処置
十分な数の接続リソースを提供したといえるようにするには、net.cfg ファイルが以下のように設定されているかどうかを確認してください。

これらの構成パラメーターの詳細については、IPX/SPX 資料を参照してください。

net.cfg ファイルは、通常はルート・ディレクトリーにあります。 このファイルは、OS/2 では NETWARE ディレクトリーにある場合もあります。 システム・ブートアップ画面を検査して、net.cfg ファイルが使用されているかを判別してください。

Windows または OS/2 クライアントからの接続時に SQL1109N を受け取った

症状
Windows または OS/2 クライアントから接続しようとすると、SQL1109N エラー・メッセージを受け取ります。

推定原因
NWCALLS.DLL ファイルおよび TLI_SPX.DLL ファイルの 2 つのバージョンがあります。 1 つは OS/2 用、もう 1 つは Windows 用です。 これらのファイルのある場所が正しくない可能性があります。

処置
Novell の NWDLL2.exe パッケージからの NWCALLS.DLLWINDOWS\SYSTEM ディレクトリーになければなりません。 Windows が OS/2 用の NWCALLS.DLL をロードしないようにしてください。

IPX/SPX 用のサーバーで SQL5043N を受け取った

症状
サーバー上で SQL5043N メッセージを受け取ります。

推定原因

処置
サーバー上にある db2diag.log ファイルを表示します。 さらに詳しい情報を提供しているメッセージを探します。

NetBIOS の問題

この節では、NetBIOS 通信プロトコルに関連する問題判別のヒントを扱います。 NetBIOS は UNIX ベースの環境では使用されません。

SQL30081N を受け取った

症状
クライアントからサーバーに接続できない場合、 普通は SQL30081N メッセージを戻りコード 0x14 とともに受け取ります。

処置
次のチェックリストを使用して、問題を診断してください。 ディレクトリー・キャッシュを使用していて、 データベースまたはノード・ディレクトリーを変更する場合、 変更が有効になるようにクライアントで TERMINATE コマンドを使用しなければなりません。

[ ]
NetBIOS listener がサーバー上で始動していますか? db2diag.log ファイル内の NetBIOS リソースを検査して、 問題があるかどうかを確かめてください。 詳細については、NetBIOS 用のサーバーで SQL5043N を受け取ったを参照してください。

[ ]
クライアントおよびサーバーが NetBIOS サポートを始動するように設定されていますか?

NetBIOS は、サーバーの構成とクライアントの構成の両方に含まれていなければなりません。

  • サーバー上で、db2set DB2COMM コマンドを使用して、NetBIOS がサポートされているプロトコルであることを確認します。
  • クライアントのデータベース・ディレクトリー内にあるノード名が、 クライアントのノード・ディレクトリー内の NetBIOS ノード項目の別名と一致していなければなりません。 クライアントのノード・ディレクトリーにあるこの別名に対応する nname は、 サーバーのデータベース管理プログラムの構成パラメーター nname の値と一致していなければなりません。

    これらの 3 つの名前が同じでない場合、 クライアントでノード項目を再カタログ化しなければなりません。 CATALOG コマンドの詳細については、コマンド解説書 を参照してください。

[ ]
クライアント上でノードをカタログ化したときに、 正しいアダプター番号を指定しましたか?

クライアントのノード・ディレクトリーに指定されているアダプターを確かめてください。 このアダプター番号は、 クライアントで NetBIOS 通信のために構成されているアダプターと一致していなければなりません。

通常、アダプター番号は 0 です。ただし、複数のアダプターが構成されている場合、 クライアントによって使用されているアダプターがサーバーに到達できる LAN 用になるようにしなければなりません。

Windows NT 上でネイティブの NetBIOS を使用している場合、 アダプター番号は論理 LAN アダプター番号 (Lana 番号) と呼びます。 この値を検査するには、以下の手順に従ってください。

  1. 「コントロール パネル」から「ネットワーク」アイコンを選択します。
  2. サービス」タブから、NetBIOS インターフェースを選択します。
  3. プロパティ」を選択します。
  4. ネットワーク経路 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/) にアクセスして、 修正方法があるどうか確認します。 (この情報は英語のみですのでご注意ください。)

NetBIOS 用のサーバーで SQL5043N を受け取った

症状
サーバー上で SQL5043N メッセージを受け取ります。

推定原因
NetBIOS listener が始動していません。

処置
サーバー上にある db2diag.log ファイルを表示します。 以下の項目を探してください。

[ ]
DIA3426C:
  • データベース管理プログラム構成を有効な nname で更新し、 インスタンスを停止してから開始します。

[ ]
DIA3409I または DIA3420C:
  • 要求された数と割り振ることのできた数との差の分だけネットワーク制御ブロック (NCB) の数、セッション、 または名前を増やします。

    これらの値は、以下のものに保管されます。

    • OS/2 の場合、protocol.ini ファイル
    • Windows 95 および Windows 98 オペレーティング・システムの場合、NetBIOS ネットワーク制御設定値
  • 他の NetBIOS アプリケーションによって使用される NetBIOS リソースを減らします。 これらのリソースが、DB2 NetBIOS リソース要求への制約になっている可能性があります。
  • 十分な NCB を割り振ることができない場合、 環境変数 DB2NBSENDNCBS および DB2NBRECVNCBS の値を検索します。 それらの値がそれらのデフォルトより大きい場合、それらの値を小さくすることができます。

    DIA3420C メッセージで割り振り可能と指示された NCB の数は、 これらの値に DB2NBINTRLISTENS および DB2NBXTRANCBS の値を加えた合計より大きくなければなりません。

  • 十分なセッションを割り振ることができない場合には、 環境変数 DB2NBSESSIONS を DIA3420C メッセージで割り振り可能と指示された値に設定してみてください。
  • protocol.ini ファイルの NetBIOS リソース・プール制限値を増やし、 ワークステーション・アダプター上の NetBIOS アプリケーションおよびドライバーによって出されるすべてのリソース要求を満たすようにしてください。

名前付きパイプの使用時の問題

SQL30082 を受け取った

症状
ワークグループ環境では、名前付きパイプを使用してデータベース・サーバーにアクセスしようとしているユーザーは、 SQL30082N メッセージを理由コード 18 (名前付きパイプ・アクセスが否認された) とともに受け取ります。

推定原因
リモート・サーバーで名前付きパイプにアクセスする前に、 システム・レベルのオープン・セッションがなければなりません。 この場合、ユーザー認証がサーバーで失敗しました。 したがって、セッションはヌル値セッションであり、 名前付きパイプにアクセスするための認証を持っていません。

処置
以下のいずれかを行ってください。

APPC の問題

APPC 接続に問題が生じた場合には、以下のチェックリストを検討してください。

[ ]
クライアントまたはサーバーのインストールの際に、 概説およびインストール にある指示に従いましたか? この資料は、APPC 構成の手順を段階的に説明しています。

[ ]
VTAM を使用している場合、サーバーおよびクライアントに正しい論理装置 (LU) 名が定義されていますか?

[ ]
正しい TP 名が定義されていますか?

[ ]
SNA を使用している場合、正しい SNA ノード ID が定義されていますか?

[ ]
DB2 ノード・ディレクトリーで適切な APPC セキュリティーを、 また DB2 データベース・ディレクトリーで適切な DB2 認証を使用していますか?

ともに使用できる認証とセキュリティーのタイプの詳細については、 概説およびインストール を参照してください。 DB2 ノード・ディレクトリー内にあるセキュリティー設定が SNA セキュリティー構成を一時変更することに注意してください。


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