DFHLD0001 0C4 AKEA at 0652 in DFHLDLD3 when NEWCOPY and using CA DADS Plus

CA DADS Plus Support recreated the problem and provided fix T3BE649.

CA's response:

 I was able to recreate this problem. I reviewed the code and found that we were changing CPE_PROGRAM_STATUS to LOCATED for programs that had been already loaded in an attempt to force a NEW COPY on those programs after we had changed the search order for DFHRPL. I have removed the offending code from our source base.

Prior to contacting CA Support, I took a look at the CICS Internal Trace in the system dump of the abend 0C4 (formatted with IPCS using VERBX DFHPDxxx 'TR=1' where xxx is your release level of CICS like 690 for CICS TS 5.2) and saw the following flow:
0001 LDLD ENTRY - FUNCTION(REFRESH_PROGRAM) PROGRAM_NAME(PROGNAME)

0501 PGIS EXIT - FUNCTION(REFRESH_PROGRAM) RESPONSE(OK) VERSION(OLD)

0001 LDLD ENTRY - FUNCTION(INQUIRE_PROGRAM) PROGRAM_TOKEN(00000048_40CC2790)

3701 LDLD3 EXC RECOVERY-ENTERED

Next I took a look in Loader domain (VERBX DFHPDxxx 'LD=1') at the CPE for this Program:

CPE.PROGNAME 00000048_40CC2790 CURRENT PROGRAM ELEMENT

The problem seems to be that field CPE_APE_CHAIN_SIZE at offset x'7C' is 1 indicating there is an APE chained from the CPE. But, the APE_OLDER_APE field (CPE +x'90', part of the CPE_APE_CHAIN_FIELDS) does not point to an APE, it points +x'68' within the CPE (as does the younger APE chain pointer):

x'7C' 00000001

x'90' and x'98' 00000048 40CC27F8 00000048 40CC27F8

The standard DFHRPL concatenation is in a modifiable section manipulated by CA DADS Plus as it allocates and deallocates load libraries.