A fix is available
APAR status
Closed as program error.
Error description
The customer is running WMQ V7.1 with z/OS V2R1 and testing with a simplex structure that has SCM defined. The structure was filled enough to force an overflow into SCM. At this point they injected an error into the structure to force recovery. The first attempt was successful. The structure was successfully recovered and we verified that were was no missing or duplicate messages. . At this point the customer attempted the exact same scenario using the same structure, queues and putting the same amount of messages. This time however the structure was only 2% full and they never overflowed into SCM. The customer verified that all 76,000 messages were put to the structure. . The change team reviewed the doc and they can now see the cause of the problem with the offload rules all being set to 0 after failing a structure. The problem occurs if CSQE035E is issued indicating an attempt to connect to the structure, but the structure is failed. What happens is that CSQECONN invokes CSQEDSG1 for CSQE_DSG1_APPLY_CHANGES, which results in STRB_new_offload_rules being set to the values from DB2. CSQEDSG1 then invokes CSQEDSC2 for CSQE_DSC2_REFRESH_OFFLOAD. However, CSQEDSC2 detects that the structure is not yet connnected, and therefore does not set STRB_offload_rules to STRB_new_offload_rules but returns CsqeRsnCodeDsConnNotActive. CSQECONN is then subsequently invoked and connects successfuly to the sturcture. However, as STRB_new_offload_rules contains the same values as in DB2, STRB_offload_rules does not get set with the current offload rules, hence they all contain 0. . In a different environment, it was observed that this issue can also occur if the RECOVER CFSTRUCT command is issued before queue manager has connected to the structure for the first time, as the STRB is not yet initialised. . For a CF structure at CF level 5 defined with OFFLOAD(DB2), all messages will be offloaded to DB2, causing the amount of CPU used by the queue manager in DB2 to increase.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: All messages for a given CF structure * * are offloaded to either DB2 or SMDS * * after a structure failure occurred, * * although the offload rules do not match * * the current state. * **************************************************************** * RECOMMENDATION: * **************************************************************** The problem occurs if CSQE035E is issued indicating an attempt to connect to the structure, but the structure is failed. What happens is that CSQECONN invokes CSQEDSG1 for CSQE_DSG1_APPLY_CHANGES, which results in STRB_new_offload_rules being set to the values from DB2. CSQEDSG1 then invokes CSQEDSC2 for CSQE_DSC2_REFRESH_OFFLOAD. However, CSQEDSC2 detects that the structure is not yet connected, and therefore does not set STRB_offload_rules to STRB_new_offload_rules but returns CsqeRsnCodeDsConnNotActive. CSQECONN is then subsequently invoked and connects successfully to the structure. However, as STRB_new_offload_rules contains the same values as in DB2, STRB_offload_rules does not get set with the current offload rules, hence they all contain 0. Additional keywords: MQSMDS/K
Problem conclusion
The code was changed to clear the STRB_New_Offload_Rules field during SMDS initialisation, allowing correct rules to be set when the next connection to the structure occurs. 100Y CSQEDSC1
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI13906
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-03-18
Closed date
2014-07-15
Last modified date
2014-10-14
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI19595 PI27591
Modules/Macros
CSQEDSC1
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UI19595
UP14/08/30 P F408 ¢
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
14 October 2014