IBM Support

PM27233: ABEND 0C4 INTO DFHIIRP

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Error message
    DFHII1012 E CICST5 Failure com.ibm.cics.domains.DomainDisaster:
              Class: Dfhiirpj,
              function: RECEIVE_REPLY, response: DISASTER,
              reason: ABEND receiving reply from IIRP.
    is issued and an abend 0c4 is detected into DFHIIRP at offset
    x'2294' base lvl.
    The root cause is that the initial RUEI in the list addressed by
    rp_frag_ruei_ptr is held in the stack storage of DFHIIRP.
    When DFHIIRP returns with EXCEPTION and BUFFER_TOO_SMALL the
    stack storage is available for any other task touse.
    Normally this task will be back in to DFHIIRP immediately with a
    bigger buffer and so will be allocated the same stack storage.
    This allows the chain of fragment buffers and rueis to be
    processed and freed.
    The problem occurs when the original task looses control
    after returning from DFHIIRP and does not run again for some
    time. In this gap another task runs and obtain the stack storage
    At this point the original task gets a different area of stack
    storage than it had last time, refering to storage unavailable
    causing the 0c4 .
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users                               *
    ****************************************************************
    * PROBLEM DESCRIPTION: ABEND0C4 at offset x'2294' in DFHIIRP   *
    *                      and message DFHII1012 is issued when    *
    *                      receiving a fragmented IIOP reply.      *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    DFHIIRP function INVOKE has been called to send an IIOP request
    to a remote system and receive the reply.  The reply being sent
    by the remote system is large and so has been broken up into
    fragments.  DFHIIRP receives the series of fragments, storing
    them in a chain a RUEI control blocks and associated data
    buffers.  This chain of RUEI control blocks is referenced from
    an initial RUEI held in DFHIIRPs local stack storage.  The
    address of the initial RUEI is held in the global rp_data block
    in field rp_frag_ruei_ptr.
    
    Once all the data has been received the length is calculated
    and found to be larger than the size of the buffer supplied to
    DFHIIRP.  DFHIIRP returns to its caller with a response of
    BUFFER_TOO_SMALL.  The caller obtains a buffer of the correct
    size and calls DFHIIRP function RECEIVE_REPLY specifying
    a RESPONSE_TYPE of OVERFLOW.
    
    At some point between returning from DFHIIRP and calling it
    again, a task on a different TCB makes a domain call that gets
    allocated the stack storage that was just in use by DFHIIRP.
    That domain call causes the storage that was previously the
    initial RUEI to be overwritten.
    
    DFHIIRP gets running again with a new area of stack storage.
    It attempts to process the RUEI chain, starting at the initial
    RUEI whose address was obtained from the global rp_data block.
    That storage is no longer a RUEI so an 0C4 abend occurs when
    the RUEI chain gets processed and an invalid address is used
    as a pointer to a RUEI or data buffer.
    
    Additional Keywords: msgDFHII1012
    ABENDS0C4  S0C4  CORBA  CORBASERVER  EJB  EJBS
    

Problem conclusion

  • DFHIIRP has been changed so that the initial RUEI is held in
    GETMAINed storage instead of local stack storage.  This allows
    it to persist validly across calls to DFHIIRP.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM27233

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    600

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-11-22

  • Closed date

    2011-02-28

  • Last modified date

    2011-04-04

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK65157

Modules/Macros

  •    DESIIRP  DFHIIRP
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R600 PSY UK65157

       UP11/03/03 P F103

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"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 April 2011