A fix is available
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 WebSphere MQ for z/OS Version 8 * * 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: * **************************************************************** 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. 000Y CSQYALLI CSQYEATE
Temporary fix
Comments
APAR Information
APAR number
PI65436
Reported component name
WMQ Z/OS 8
Reported component ID
5655W9700
Reported release
000
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-07-06
Closed date
2016-07-12
Last modified date
2017-03-31
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI39325
Modules/Macros
CSQYALLI CSQYEATE
Fix information
Fixed component name
WMQ Z/OS 8
Fixed component ID
5655W9700
Applicable component levels
R000 PSY UI39325
UP16/07/28 P F607
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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
31 March 2017