サード パーティ製の診断ツールは、Micro Focus ソフトウェアにおける問題の原因を特定するのに非常に役立ちます。
シナリオ 1:コア ファイルが生成されない
Windows 環境で特に役立つツールの 1 つは、Process Monitor (ProcMon) アプリケーションです。Process Monitor は、Windows SysInternals ツール スイートの一部で、Microsoft
の Web サイトからダウンロードできます。
ProcMon は、パスとレジストリへのアクセス、およびシステム全体で実行された検索を表示できます。すべてのアクセスおよび検索を表示したり、その結果をフィルター処理して特定の情報を表示したりできます。次の例は、コア ファイルの生成における問題、および
ProcMon を使用して問題をトラブルシューティングする方法を示しています。
- 問題
- cobconfig.cfg ファイルで、アプリケーションがクラッシュした場合に MFCore.pid@time_date という名前のコア ファイルを c:\logs ディレクトリに生成するように、core_on_error および core_filename ランタイム チューナーを設定しました。しかし、アプリケーションがクラッシュしても、コア ファイルが生成されていないようです。
- ProcMon によるトラブルシューティング
- ProcMan アプリケーションは、対象とするアプリケーションと同時に実行され、設定されたフィルターに基づいてそのアクティビティを追跡します。次の手順を使用して、コア ファイルの生成に関する問題をトラブルシューティングできます。
- ProcMon を起動し、フィルターを設定して、文字列 MFCore を含むパスへの参照をすべてトレースします。

- クラッシュするようにアプリケーションを再実行します。
- ProcMon で出力を表示します。

この例では、ProcMon の出力から、設定したランタイム チューナーによって logsMFCore... という名前のファイルが C: ドライブのルート ディレクトリに作成された (MFCore... という名前のファイルが C:\logs ディレクトリにではなく) ことがわかります。これは、core_filename ランタイム チューナーの定義方法に誤りがあることを示しています。
- cobconfig.cfg ファイルを編集します。現在は次のようになっています。
set core_on_error=131
set core_filename="C:\\logs\MFCore.%p@%t_%d"
core_filename に設定されている値を調べると、logs ディレクトリの指定とファイル名の指定の間にバックスラッシュ (\) が 1 つしかないことがわかります。
cobconfig.cfg ファイル内のバックスラッシュ文字はエスケープされるため、この単一のバックスラッシュが削除されて、間違った場所にファイルが配置されていました。
- 次のように、core_filename の値でのディレクトリ指定の後に 2 つ目のバックスラッシュを追加します。
set core_filename="C:\\logs\\MFCore.%p@%t_%d"
- 保存してエディターを閉じます。
- アプリケーションを再実行します。今度は、アプリケーションがクラッシュすると、コア ファイルが正しい場所に表示されます。
シナリオ 2:Windows マシンから UNIX Fileshare サーバーに接続できない
- 問題
- Windows マシンを Fileshare クライアントとして設定し、Redhat Linux を実行しているリモートの Fileshare サーバーへのポート 8765 を使用したリモート接続を定義したところ、Fileshare サーバーへの接続が機能しません。
- ncat によるトラブルシューティング
- このようなシナリオで最初に確認すべき点は、Windows マシンへのネットワーク接続です。そのために、ncat (NCAT.ORG から入手可能) を使用して、ごく基本的なクライアント/サーバー接続をセットアップできます。ncat の接続が機能する場合は、ネットワークの問題が原因である可能性を除外できます。このシナリオでは、次の ncat コマンドを実行できます。
このシナリオでは、両方の接続が正常に確立されました。次のステップは、接続自体で何が起きているかを調査することです。
- Wireshark および tcpdup によるトラブルシューティング
- tcpdump と Wireshark を組み合わせて使用して、ネットワークを通過するトラフィックを分析できます。どちらも、ネットワークに関するさまざまな問題を分析するのに役立つ強力なツールです。
Windows (クライアント) マシンで Wireshark を実行すると、送信に対する応答が受信されていないことがわかります。これは、Redhat (サーバー) 側に何らかの問題があることを示唆しています。これをトラブルシューティングするには、次の手順を実行します。
- Windows (クライアント) マシンで Wireshark を起動します。
- サーバー マシンの IP アドレスへの接続を表示するようにフィルターを設定します。
- Fileshare サーバーが実行されているポート 8765 に tcp 要求を送信します。
- 出力を表示します。

この出力から、ポート 8765 に要求を送信したものの、応答を受信していないことがわかります。
Redhat (サーバー) 側で何が起きているかを調べるには、tcpdump を使用できます。これは、Wireshark に似た機能を持つ、Unix/Linux システム用のツールです。
- 解決方法
- 環境をさらに調査したところ、ファイアウォールが 3000 を超えるポート番号での要求をブロックしていることがわかりました。つまり、ncat の接続は、ポート 2000 で実行されたため成功しましたが、Wireshark/tcpdump の接続は、ポート 8765 がファイアウォールでブロックされていたため成功しませんでした。