Once you have identified a heap corruption, you are in for a bit of work. This type of issue is not typically resolved on the first attempt, and often requires several iterations to successively cut down the "window" in which it took place and then isolate the exact statement causing the problem.
The type of memory and the flags are good clues that can eventually lead you to pinpointing the problem.
We recommend that you start by setting the COBOL memory_strategy run-time tuneable to 80000003, which uses an example file defined by the COBCONFIG environment variable in your enterprise server region:
set memory_strategy=0x80000003
The change causes corruption checking to occur more frequently and more completely than the defaults. Because PL/I makes extensive use of HEAP memory for temporary variables, etc., this could cause the error to occur much sooner than usual. If the program is well written and uses a ON ERROR with a call to PLIDUMP(), then you should have a detection point that narrows the window to some time just before that point.
For IMS programs, use the MFIMS_MEM_DIAG environment variable to possibly shrink your window further:
MFIMS_MEM_DIAG=2
If the corruption was caused by a PLITDLI or EXEC DLI statement where the buffer to receive a segment was too small for the segment data, or any other cause where IMS corrupted some memory unintentionally, MFIMS_MEM_DIAG causes checks at strategic points within the IMS engine to detect if/when a corruption occurs. These checks and their results are reported in the IMS BTS tracing.
For IMS and all other programs, if you have yet to resolve your heap corruption, continue to reduce the window using the suggestions provided in Isolating the PL/I Procedure in which the Corruption Occurred.