PI46709: WMQ Z/OS V8: ABEND0C4 IN CSQXCCAX AND CSQXRCAP

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The CHIN log has these errors:
  
  CSQX112E CSQXDISP Dispatcher process error, TCB=008C32C0
   reason=0C4000-00000004
  CSQY291E CSQXDMPS SDUMPX FAILED, RC=00000208,ssid,ABN=
   0C4-00000004,LOC=CSQXRCTL.CSQXRCAP+002E8
  IEA794I SVC DUMP HAS CAPTURED:
   DUMPID=002 REQUESTED BY JOB (ssidCHIN)
   DUMP TITLE=ssid,ABN= 0C4-00000004,C=W9700.800.CHIN,M=
   CSQXDISP,LOC=CSQXRCTL.CSQXCCAX+04088
  
  Several sets of these abends occurred (to match the number of
  dispatcher TCBs in CHIDISPS) and then the following error
  occurred:
  IEA794I SVC DUMP HAS CAPTURED:
   DUMPID=003 REQUESTED BY JOB (ssidCHIN)
   DUMP TITLE=ssid,ABN= 5C6-00E70004,C=W9700.800.CHIN,LOC=
   CSQXSUPR.CSQXSCHD+004F8
  
  00E70004 means CSQX_ABEND_NO_DISPS_AVAILABLE
  
  The ABEND0C4 in CSQXCCAX was first. The failing instruction is
  58E0 E96C due to Reg14 being zeroes. It should point to an
  rriSession.
  
  L3 found that leading up to the problem, a new conversation for
  a client channel is being started. rriAsyncConvControl invokes
  rriGetChannelDef which results in an MQOPEN being issued for
  the channel object. CSQMCPRH allocates an ACE control block for
  use by the new conversation. However, this ACE has ACESTOP set
  (it must have been previously in use and an
  lpiSPINotify_BREAKCONN issued). Due to changes at V8, ACESTOP
  does not get reset, which means that the MQOPEN fails with MQRC
  2009, MQRC_CONNECTION_BROKEN. This then leads to the ABEND0C4s.
  
  
  Additional Symptom(s) Search Keyword(s):
  ABEND0C4 ABENDS0C4 0C4 S0C4 S00C4
  ABEND5C5 ABENDS5C6 5C6 S5C6 S05C6
  .
  +CSQX007E <SSID> CSQXRESP Unable to connect to
   queue manager MQCC=2 MQRC=2009
   (MQRC_CONNECTION_BROKEN)
  +CSQX599E <SSID> CSQXRESP Channel <channel_name>
    ended a connection xxx.xxx.xxx.xxx
  

Local fix

• Circumvent the problem by issuing the following MQ command:
  
   /cpf RECOVER QMGR(TUNE CICSFastDealloc OFF)
  
  where "cpf" is the command prefix for the queue manager.
  
  This setting does not persist across restarts of the queue
  manager, so the command will need to be issued when the queue
  manager starts again, e.g. from a CSQINP2 member.
  
  This will disable a CICS/CHIN performance optimization added at
  V8 which is preventing ACESTOP from being reset. Disabling the
  performance optimization will give the same behavior as at
  V710.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Starting a conversation on a channel    *
  *                      which reuses an ACE from the free chain *
  *                      that has ACESTOP still set will result  *
  *                      in message CSQX007E being produced with *
  *                      MQRC 2009.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When a new conversation is started by the channel initiator for
  a channel, the channel definition may be read from queue
  manager. However during this when the object is opened, a ACE
  will be taken off the free chain, however if this was previously
  used, it is possible for the ACESTOP flag to be set. This will
  result in the MQOPEN of the channel object to fail, with MQRC
  2009. This results in the conversation not starting and message
  CSQX007E to be produced in the chinit.
  

Problem conclusion

• CSQMCPRH, which can deal with putting the ACE on and off the
  free chain has been updated to ensure the ACESTOP flag is
  correctly reset for these operations, allowing the MQOPEN to
  correctly complete.
  000Y
  CSQMCPRH
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UI33289

Modules/Macros

• CSQMCPRH
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI33289

     UP16/01/08 P F601 ¢

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.