Question & Answer
Question
When attempting to perform a NEWCOPY of a program in CICS, why would I receive DFHLD0001 An abend (code 0C4/AKEA) has occurred at offset X'0652' in module DFHLDLD3? I am using CA DADS Plus from CA Technologies which allocates and deallocates load libraries from the DFHRPL.
Answer
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.
Product Synonym
CICS/TS CICSTS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
04 August 2016
UID
dwa1292819