PI65445: WMQ JOB TASK TERMINATES WITH ABEND0D7 00000025 IN CSQYALLLI

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Job task terminates when SSAR is issued out of program address
  space. Change Team finds TCB x is trying to connect to MQ at
  the same time as TCB y is connecting to DB2. TCB y has issued
  an AXEXT, seen that the current AX value is 0, and then issued
  an AXRES to obtain a new AX (authorization index). However this
  processing has been suspended on the CML lock for the PCAUTH
  address space as TCB x is in the middle of an AXEXT. TCB x
  then detects that the current AX value is 0 so issues an AXRES
  which returns a new AX value of 001F. Processing continues and
  an AXSET is issued for the next AX value and then the queue
  manager gives SSAR and PT authority to the AX value. However,
  TCB y then continues processing and the AXRES returns a new AX
  value of 0021. TCB y then issues an AXSET for the AX value of
  0021. Therefore when TCB x tries to issue a SSAR to the queue
  manager address space, the current AX value is 0021 which does
  not have SSAR authority to issue SSAR to the queue manager
  address space, resulting in the S0D7 abend.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of IBM MQ for z/OS Version 9 Release 0             *
  * Modification 0.                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Abend 0D7-00000025 occurs in CSQYALLI when an application    *
  * connects to the queue manager for the first time.            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * None                                                         *
  ****************************************************************
  An application started and connected to both MQ and DB2 at the
  same time. During MQCONN processing CSQYALLI was called and
  issued AXEXT to extract the current AX value for the address
  space. At the same time DB2 also issued AXEXT and also found
  that there was no AX value set.
  
  Both MQ and DB2 issued AXRES to reserve an AX. MQ then issued
  AXSET to set the AX to the value it had reserved, and then
  granted this AX SSAR authority to the queue manager address
  
  space.
  
  However DB2 then issued AXSET and changed the AX value to the AX
  it had reserved.
  When MQ subsequently attempted to SSAR to the queue manager
  address space, the AX was no longer the value that had been
  granted SSAR authority, and so the SSAR abended 0D7-00000025.
  

Problem conclusion

• CSQYEATE is changed to detect when it is called during recovery
  of a 0D7-00000025 in CSQYALLI, and check if it is due to the AX
  having changed. If this is the case, SSAR authority is granted
  to the new AX value and recovery processing retries, allowing
  CSQYALLI to reissue the SSAR and continue processing.
  

Temporary fix

Comments

APAR Information

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

  PI65249

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

  UI41302

Modules/Macros

• CSQYALLI CSQYEATE
  

Fix information

• Fixed component name

  MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R000 PSY UI41302

     UP16/10/14 P F610

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.