このセクションでは、メッセージ・フローを開発する際に生じる可能性のある共通問題のいくつかについて概説します。 このセクションには、以下の問題を処理するためのアドバイスが含まれます。
このエラーによって、メッセージは failure ターミナルに送信されます。
MQInput ノードの failure ターミナルを out ターミナルではなく、連続するノードに誤って接続した可能性があります。 out ターミナルは、3 つのターミナルのうちのトップではなく、真ん中のターミナルです。未接続の out ターミナルに送信されたメッセージは廃棄されます。
MQInput ノードの failure ターミナルが、たとえば、MQOutput ノードと接続している場合には、これらのメッセージは現れません。
あるノードと他のノードの failure ターミナルとの接続は、すべてのエラー処理を扱えるようにメッセージ・フローを設計したことを示します。 failure ターミナルと MQOutput ノードを接続した場合、メッセージ・フローは発生するエラーを無視します。
詳しくは、トレースの使用を参照してください。
このアクションは、メッセージが送信されるすべてのノードから、そしてこれらのノードからのみユーザー・トレース・エントリーを生成します。
分散プラットフォームでは、mqsireadlog コマンドを使用してトレース・エントリーを検索したり、mqsiformatlog コマンドを使用してそれらをフォーマットすることができます。また、フォーマットされたレコードを表示して、メッセージ・フローによってメッセージのパスをチェックすることができます。これらのコマンドの詳細については、コマンドを参照してください。
z/OS の場合、COMPONENTPDS にあるジョブ BIPJLOG を編集および送信して、mqsireadlog および mqsiformatlog を実行してトレースを処理してください。ユーティリティー・コマンドの詳細については、z/OS ユーティリティー・ジョブを参照してください。
メッセージをメッセージ・フローに再度送信してください。 Debug レベルのトレースによって、メッセージがその経路を取る理由についてさらに詳細な情報を入手できます。また、これによって、メッセージ・フローが実行するアクションの理由を判別することができます。
問題を解決した後、トレースを必ずオフにしてください。そうしない場合、パフォーマンスに悪影響を与える場合があります。
一般に:
メッセージ・フローが、障害ではないものの出力キュー (または他の持続的なストア) で終わらないパスを持っている場合、メッセージ・フローは失敗しておらず、メッセージはバックアウトされません。また、代わりの宛先 (たとえば、catch ターミナル、送達不能キュー、またはキューのバックアウト・キュー) にも書き込まれません。
SQL0954C Not enough storage is available in the application heap to process the statement.z/OS では、HY014 の SQLSTATE は SQL コード -99999 で戻される可能性があります。 これは、DataFlowEngine プロセスが、 準備済み SQL ステートメントが処理する DB2 z/OS 処理限界の 254 ハンドルに達したことを表します。
パフォーマンス上の理由で、ステートメントが準備された後、 ステートメントおよびハンドルはキャッシュ内に保管され、 SQLPrepare 関数への呼び出し回数を削減します。 ステートメントがすでにキャッシュ内にある場合、ステートメント・ハンドルが戻され、 新規の結合パラメーターで再実行できるようにされます。
ステートメント・ストリングを使用して、キャッシュ検索を実行します。 各メッセージごとに多少異なる、ハードコーディングされた SQL ストリングを使用すると、 ステートメントはキャッシュ内に見つからず、SQLPrepare 関数は常に実行されます (また、 新規の ODBC カーソルがオープンされます)。 PASSTHRU ステートメントを使用する場合、パラメーターを実行時に結合したまま、 同じ準備済み SQL ステートメントを処理するメッセージごとに使用できるように、 パラメーター・マーカーを使用してください。 この方法は、データベース・リソースに関してより効率的であり、 繰り返し実行されるステートメントに関してもより高速になります。
しかし、パラメーター・マーカーを常に使用できるわけではありません。 また、実行時に SQLステートメント・ストリングを動的に作成したいと思うかもしれません。 これによって、多数の固有 SQL ステートメントがキャッシュされる可能性があります。 これらのステートメントは一般的に大きくないため、キャッシュ自体はそれほど大きくなりません。 しかし、少ないメモリー割り振りが多数あると、メモリーのフラグメント化が生じる可能性があります。
任意の与えられたメッセージ・フローに対して、 標準的なノードでは約 2 KB のスレッド・スタック・スペースが必要です。 デフォルトでは、UNIX プラットフォームの単一メッセージ・フロー内では約 500 ノード、Windows プラットフォームでは 1000 ノードの限度があります。 この限度は、各ノード内で実行されている処理のタイプによって、 大きかったり小さかったりする可能性があります。
この環境変数設定はブローカーに適用されるため、 MQSI_THREAD_STACK_SIZE は、 DataFlowEngine プロセス内で作成される各スレッドごとに使用されます。 実行グループに割り当てられる多数のメッセージ・フローがあり、 大きな MQSI_THREAD_STACK_SIZE を設定すると、 DataFlowEngine プロセスはスタック用の大量のストレージを必要とします。
Video_Test#FCMComposite_1_1 ComIbmMQInputNode , Video_Test.VIDEO_XML_IN
WebSphere MQ Everyplace メッセージ内に含まれているデータを解析または変更する必要がある場合には、MQeMbMsgObject を使用してください。これらは、標準の WebSphere MQ メッセージとの並列性を備えています。相関 ID といったフィールドを設定できます。また、WebSphere Business Integration Event Broker パーサーを使用して解析可能なフィールドがあります。
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
au16530_ |