PI13906: AFTER CSQE035E IS PRODUCED WHEN THE STRUCTURE IS IN FAILED STATE, MESSAGES ARE OFFLOADED TO DB2 OR SMDS UNEXPECTEDLY

Obtain the fix for this APAR.

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 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.