PH29229: ABEND ABN= 0C4-00000011,C=MQ900.910.CHIN,M=CSQXDISP,LOC=CSQXRCTL.CSQXCCAX

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The channel which encounters a problem is a multiplexed SVRCONN
  with SSL enabled.
  
  The following processing occurred in the run-up to the 0C4
  abend:
  
  - The channel has several conversations active, but none of
  them have been actively doing any MQ work for some time.
  
  - As there has been no proper activity on the channel, the last
  few requests are all heartbeat flows which check that the
  channel connection is still ok while no real work is being done.
  
  - Because the channel is using SSL, and the qmgr is configured
  with an SSL key reset value, the first piece of work after a
  heartbeat results in an SSL key reset being negotiated.
  
  - The last request from the client before the abend is the
  start of the processing for an SSL key reset, asking the server
  to pause channel activity (e.g. asynchronous consumers) so that
  the key reset can proceed uninterrupted.
  
  - The failing function, ccxReceiveThreadFn, is responsible for
  processing incoming requests from the client, and has a loop
  which handles one request at a time. While processing the pause
  request, it attempts to obtain a value from a field in the
  session control block (TraceIdentifier). The pointer to the
  session block (psess) is invalid, resulting in the 0C4.
  
  For the pause request, the psess variable isn't initialized, so
  it would contain a residual value from a previous client
  request. Generally this would still be a valid session for one
  of the conversations on the channel so the pause would work ok
  in most circumstances.
  
  In this case the last request before the heartbeats was a
  request to end a conversation. This would have resulted in
  psess being set to the session block for the conversation which
  is ending, and the session block would have been freed as part
  of the clean-up of the conversation.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0 and Release 2       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: When using a multiplexed SSL channel    *
  *                      with multiple conversations, if an SSL  *
  *                      key reset interval is specified, then a *
  *                      precise FAP flow involving a            *
  *                      conversation disconnecting can result   *
  *                      in an ABEND0C4 in the CHIN.             *
  ****************************************************************
  As part of end of conversation processing, the CHIN frees
  control blocks which it no longer needs. A flaw in the
  multiplexed receiver code can result in one of these freed
  conversation blocks being reused. This code is primarily driven
  when performing an SSL key reset, and depending on whether the
  storage page has been released by RSM, an ABEND0C4 may occur.
  

Problem conclusion

• The multiplexed receiver code has been changed to no longer
  reference freed MQ control blocks.
  

Temporary fix

Comments

APAR Information

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

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

  UI72042 UI72043

Modules/Macros

• CSQXCCAX
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R100 PSY UI72042

     UP20/12/04 P F012

• R200 PSY UI72043

     UP21/01/04 P F012

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.