ここでは、アプリケーション実行時に発生する異常終了の事例とその対処方法について説明します。
多階層システムのアプリケーション間連携時に処理要求が無応答となる
3階層システムなどでコンポーネントトランザクションサービスを構成すると、以下の図に示すとおり接続している端末数に対して多くの接続資源を消費します。
各クライアントアプリケーションはトランザクションアプリケーションAに処理要求を行い、さらにトランザクションアプリケーションAはトランザクションアプリケーションBへ処理要求を行います。
図中の1から4の処理で、コンポーネントトランザクションサービスの処理スレッドが使い切られているため、アプリケーション間の処理要求時(5および6)に必要な処理スレッドが不足し、CORBAサービスで処理要求が待ち状態となり、クライアントAおよびクライアントBの処理要求のいずれも復帰することができません。したがって、処理スレッドが解放されず、デッドロックが発生して、クライアントでは処理要求が無応答となります。
このため、各処理要求に対する受付順番によりデッドロック状態となり、処理要求が無応答となることがあります。
この場合、システムログに以下のメッセージが出力されます。
TD: 警告: td12038: 最大接続クライアント数に達しました(ORB- PID) ORB:ワークユニット種別を表示します。 PID:最大接続クライアント数を表示します。
処理要求が無応答となり、上記メッセージが出力されている場合は、メッセージの[ユーザの対処]に記載しているように、システム規模を見直す必要があります。
参照
システム規模の変更については、「運用ガイド(基本編)」を参照してください。
サーバから不完全な文字列型データが復帰する
以下の条件の場合に、クライアントアプリケーションに復帰したデータが途切れるなど、不完全な状態になることがあります。
サーバアプリケーションにCOBOLを使用している。かつ、
IDL定義に文字列型で宣言している。かつ、
サーバアプリケーションで、文字列以外のデータ(バイナリデータや数値データなど)を設定している。
この場合、サーバアプリケーションで設定したデータに0x00のコードが含まれている可能性があります。
サーバアプリケーションの処理を見直してください。
なお、本現象については、「アプリケーション作成ガイド(コンポーネントトランザクション編)」の「トランザクションアプリケーション作成上の注意点」を参照してください。
富士通標準コード変換(iconv_open関数)が異常復帰する
富士通標準コード変換のiconv_open関数が復帰コード:22(指定された変換元コード系と変換先コード系の組み合わせはサポートされていません)で復帰した場合、富士通標準コード変換が動作せずに、libc.soに含まれる関数が動作している可能性があります。
この場合、tdlinknormapmコマンドでAPMを再作成して、富士通標準コード変換のライブラリをAPMの先頭に結合してください。
アプリケーションで出力した標準出力/標準エラー出力が、カレントフォルダ配下のstdoutファイルまたはstderrファイルに出力されない
アプリケーションより標準出力/標準エラー出力に対して出力されたデータは、カレントフォルダ配下のstdoutファイル/stderrファイルに出力されますが、Microsoft(R) Visual C++ .NET/Microsoft(R) Visual C++ 2005を使用してビルドしたアプリケーションでは、標準出力/標準エラー出力に対して出力されたデータが、カレントフォルダ配下のstdoutファイル/stderrファイルに出力されません。
正しく出力するためには、アプリケーションのプログラムの先頭に以下のコードを追加してください。
freopen("stdout", "w", stdout); freopen("stderr", "w", stderr);
注意
Microsoft(R) Visual C++ 2005を使用してビルドした場合、以下の警告が出力されることがありますが、動作上の問題はありません。
warning C4996: 'freopen' が古い形式として宣言されました。
前出口プログラムを使用する場合は、前出口プログラムの先頭に追加してください。前出口プログラムに追加した場合、本処理および後出口プログラムへの対処は必要ありません。
前出口プログラムを使用しない場合は、本処理の先頭に追加し、かつ、初回呼び出し時のみ実行されるよう対処してください。
ワークユニット出口プログラム/プロセス回収出口プログラムを使用する場合は、各出口プログラムの先頭に追加してください。