ヒープ破損を特定した後、いくつかの作業が必要になります。この種の問題は一般に 1 回では解決せず、問題が発生した「ウィンドウ」を少しずつ絞り込みながら、問題の原因となっている正確な文を特定するまで、数回の反復が必要になることがよくあります。
メモリのタイプとフラグは、最終的に問題の特定につながる良い手がかりとなります。
最初に COBOL の memory_strategy ランタイム チューナーを 80000003 に設定することをお勧めします。これにより、COBCONFIG 環境変数で定義されたサンプル ファイルがエンタープライズ サーバー リージョンで使用されます。
set memory_strategy=0x80000003
この変更により、破損チェックがデフォルトよりも頻繁かつ完全に実行されるようになります。PL/I は一時変数などに HEAP メモリを大量に使用するため、通常よりもはるかに早くエラーが発生する可能性があります。プログラムが適切に記述されていて、PLIDUMP() の呼び出しで ON ERROR を使用していれば、その直前のある時点までウィンドウを絞り込む検出ポイントが見つかるはずです。
IMS プログラムの場合、MFIMS_MEM_DIAG 環境変数を使用してウィンドウをさらに絞り込める可能性があります。
MFIMS_MEM_DIAG=2
PLITDLI 文または EXEC DLI 文のセグメントを受信するためのバッファーがセグメント データに対して小さすぎること、または他の何らかの理由で IMS が一部のメモリを意図せずに破損したことが原因で破損が発生した場合、MFIMS_MEM_DIAG は IMS エンジン内の戦略的なポイントでチェックを実行して破損の発生を検出します。これらのチェックとその結果は、IMS BTS トレースで報告されます。
IMS を含むすべてのプログラムについて、ヒープ破損がまだ解決しない場合は、「破損が発生した PL/I プロシージャの特定」に示す方法を使用してウィンドウをさらに絞り込んでください。