IV66989: CLUSSDR channel goes into STOPPED state after issuing command "REFRESH CLUSTER(*) REPOS(YES)"

APAR status

• Closed as program error.

Error description

• During the REFRESH CLUSTER REPOS(YES) operation, all CLUSSDR
  channels are stopped so that their state can be replaced freely.
  However, in some cases, the channels could be left in STOPPED
  status, even after the REFRESH was complete. Therefore they
  would not start except by manual intervention, via a START
  CHANNEL command.
  
  Because the channels did not start automatically, and the user
  was not aware of this possibility in advance, their applications
  on the queue manager where the REFRESH CLUSTER REPOS(YES) was
  performed would see 2189 MQRC_CLUSTER_RESOLUTION_ERROR reason
  codes from MQOPEN calls in their applications.
  
  The STOPPED state described above was more likely if the Cluster
  Queue Manager object relating to that channel had earlier been
  removed from the cluster via the RESET CLUSTER command.
  
  It has also been noticed that remarks in the Knowledge Center
  should be clarified to point out that the channels will be
  stopped automatically.
  
  WebSphere MQ 7.* > WebSphere MQ > Reference > Administration
  reference > MQSC reference > The MQSC commands > REFRESH CLUSTER
  

Local fix

• Manually start the CLUSSDR channel if it goes into stopped
  state after performing "REFRESH CLUSTER(*) REPOS(YES)"
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users who run REFRESH CLUSTER REPOS(YES).
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  The cluster cache remembers old records, relating to previous
  states of a Cluster Queue Manager object. Data that is not
  current might be held for up to 90 days, though by design this
  is invisible to users via the runmqsc commands - eg. DISPLAY
  CLUSQMGR.
  
  Due to coding errors, during the REFRESH CLUSTER REPOS(YES)
  operation, the IBM MQ code was becoming confused about the state
  of the CLUSSDR channels relating to the various historical
  records of the Cluster Queue Manager.
  
  Because of this confusion, the queue manager executing the
  REFRESH CLUSTER REPOS(YES) code left channels in STOPPED state
  after the operation was finished. This is not correct.
  

Problem conclusion

• The coding errors have been removed. The CLUSSDR channels will
  now correctly return to INACTIVE state after the REFRESH CLUSTER
  REPOS(YES) operation has completed.
  
  In addition, some clarifications will be made in the Knowledge
  Center pages describing the REFRESH CLUSTER REPOS(YES)
  operation. Specifically it will describe that the CLUSSDR
  channels will all be ended during the operation, and will be
  left in INACTIVE state afterwards.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.0       7.0.1.14
  v7.1       7.1.0.7
  v7.5       7.5.0.6
  v8.0       8.0.0.3
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

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

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

  PI39044

Fix information

• Fixed component name

  WMQ AIX V7

• Fixed component ID

  5724H7221

Applicable component levels

• R700 PSY

     UP