DFHAP0707 abend 0C7 AKEB occurs in TRUE EYU9XSTR after upgrade of CPSM

Using the following analysis of the dump I was able to determine this problem was occurring due to an application overlay of a CICS control block.

The 0C7 abend indicates that a data exception has occurred which is usually due to a field not being packed or an overlay.

Taking note of the psw and registers for the abending task I see that the psw is pointing to an EDIT (ED) instruction: DE05 6000 D091 around offset x'262' in module EYU9XSTR. Looking at Register 13 + offset x'91', it does not contain a packed decimal value so this is why the 0C7 abend occurred. Just prior to this EDIT command in the code, within routine XSTR_TASK_EIB_SET, I see that Register 4 is the EIB address. And Register 4 + x'C' (EIBTASKN) was moved into Register D + x'90'. As well Register 4 + x'8' (EIBTRNID) was moved into Register D + x'94'. Both of these addresses are invalid.

This is what the EIB (Exec Interface Block) looks like with the invalid task number and transaction ID:

  EIB.12345 270000D0 EXEC Interface Block
 
 -0010 00656EC4 C6C8C1D7 6DC4C6C8 C5C9C25C *..>DFHAP_DFHEIB**
  0000 0170045C 0114014F 66A576B8 80FDA388 *...*...|.v....th*
  0010 8A031000 00000000 00000000 00000000 *................*
  0020 0000001C 293FC738 26ED89DC 25BAADC8 *......G...i....H*
  0030 26ED85C5 E8E4F9E7 E2E3D900 00000000 *..eEYU9XSTR.....*
  0040 00000000 00000000 00000000 00000000 *................*
  0050 00000000 00                         *.....           *

The abend is occurring because the EIB has been overlaid at x'8' and x'C'.

To try to determine which application is overlaying this control block I recreated this problem and used CEDF to step through the code. I checked after each EXEC CICS command whether the EIBTASKN is intact or not. This helped narrow down which program is doing the overlay.

I also tried turning on storage protection (STGPROT) and transaction isolation (TRANISO) to help narrow down the culprit.