IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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 number

    IV66989

  • Reported component name

    WMQ AIX V7

  • Reported component ID

    5724H7221

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-11-17

  • Closed date

    2015-04-14

  • Last modified date

    2015-04-14

  • 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

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCPQ63","label":"APAR \/ Maintenance"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 April 2015