A fix is available
APAR status
Closed as program error.
Error description
A CICS region starts receiving many, many system dumps with title: ' CICS SYSTEM DUMP REQUESTED BY DFHIRP'S MESSAGE EXIT FRR' DFHIRP will take this dump when it runs out of a fixed set of buffers to receive XCF messages. These buffers contain work arriving from other CICS regions. When looking at LOGDATA, we noticed 0C4's occurring after the 0C1, which is not expected. Following each 0C1 at offset x'3F78' into DFHIRP, was an 0C4, caused by a bad PSW address. This then percolated to another 0C4 in csect name: IXCS1STB. So there was a pattern of dumps- 0C1/0C4/0C4 - repeated over and over. Understanding why DFHIRP initiated the 0C1 dump, we found a task was in a loop on the QR TCB issuing EXEC CICS SYNCPOINT commands over and over. This prevented the CSNC task, who would process these XCF messages, from running. Since CSNC was not able to process these messages, the buffers filled up, ran out. In this situation, CICS forces an 0C1 branching to label IRSWMCEH. Control goes to routine IRMXFRR- the XCF Message Exit FRR, which issues an SDUMPX macro to take a dump titled: "CICS SYSTEM DUMP REQUESTED BY DFHIRP'S MESSAGE EXIT FRR' This is the 0C1 dump, which is the only one we expect. The code then issues the SETRP macro to set a return address and indicate 'retry'. Here is where the problem is. CICS is passing R15 for this return address, which is incorrect- R15 cannot be used, only R2-R12 can be specified. This causes a wild branch when the retry is attempted, and the 0C4. This APAR is being taken to address these subsequent 0C4s due to passing a bad return address on the SETRP macro. Additional Symptom(s) Search Keyword(s): KIXREVxxx ABEND0C1 ABEND0C4 Cross-System Coupling Facility XCF Functional Recovery Routine FRR ladder MRO session
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All CICS users * **************************************************************** * PROBLEM DESCRIPTION: DFHIRP can cause 2 unexpected 0C4 * * abends after running out of XCF buffer * * space. * **************************************************************** A looping task in a CICS region can prevent CICS transaction CSNC from removing messages from DFHIRPs buffers to CICS storage. If DFHIRP runs out of XCF buffer space it reports this by using an architected 0C1 abend. A system dump is taken for this abend by DFHIRP's FRR routine. After this, R15 is invalidly used as the RETADDR on a SETRP macro. The use of R15 can cause 2 additional and unexpected 0C4 abends, each of which cause their own system dump to be taken. It is possible for DFHIRP to report the XCF buffer space error condition multiple times in quick succession. This results in a large number of SDUMP requests in a very short space of time, which may adversely affect other subsystems on the LPAR.
Problem conclusion
DFHIRP has been changed to correct the register usage on the SETRP macro. This prevents the unwanted 0C4 abends. DFHIRP has also been changed to add additional symptom information to the SDUMP that is taken. This allows DAE to suppress any duplicate dumps.
Temporary fix
Comments
APAR Information
APAR number
PH24327
Reported component name
CICS TS Z/OS V5
Reported component ID
5655Y0400
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-04-12
Closed date
2020-04-27
Last modified date
2020-05-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI69195 010PC2 010PC2 UI69196 010PC2 010PC2 010PC2
Modules/Macros
DFHIRP
Fix information
Fixed component name
CICS TS Z/OS V5
Fixed component ID
5655Y0400
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
04 May 2020