IBM Support

PH24327: RECEIVE MANY SYSTEM DUMPS REQUESTED BY DFHIRP'S MESSAGE EXIT FRR FOLLOWED BY MANY OTHER 0C4 DUMPS WHICH ARE NOT EXPECTED

A fix is available

Subscribe

You can track all active APARs for this component.

 

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

  • R100 PSY UI69196

       UP20/04/28 P F004

  • R200 PSY UI69195

       UP20/04/28 P F004

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