IBM Support

IT34895: After failure in MQ appliance makedrsecondary command the HA/DR Queue manager failed to start on second node

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • Two appliances (HA_APP1 and HA_APP2 ) were configured in a HA
    pair with a third appliance (DR_APP1) for disaster recovery.
    A queue manager (QM1) was started on HA_APP1.
    
    The command "makedrsecondary -m QM1" was invoked on HA_APP1 to
    move the queue manager to DR_APP1 but the endmqm took a long
    time, causing the command to fail with the error message :
    
         "AMQ6546E: An internal IBM MQ Appliance error has
    occurred."
    
    "sethapreferred QM1" was invoked on HA_APP2 to move the Qmgr
    there.  The command completed without errors but the queue
    manager did not start.
    
    "makedrsecondary -m QM1" was invoked on HA_APP2 to move the
    queue manager to DR_APP1.
    The queue manager started on DR_APP1 but this triggered a full
    resync of the queue manager disk on HA_APP2.  The
    resync was not expected and should not have been necessary.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of the IBM MQ Appliance 9.1 and later
    who have queue managers set up in a HA/DR configuration.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    When endmqm took a long time to run on HA_APP1, a defect was
    triggered in the error handling
    code in the "makedrsecondary" command.  This left the queue
    manager's cluster resources in a
    state where they were blocked from connecting to the cluster.
    
    This prevented the queue manager from starting on a second
    appliance, and left the second
    appliance in a standalone state which required a full resync of
    the disk to resolve.
    

Problem conclusion

  • The defect has been fixed so that the resources cannot be left
    in this state which prevents
    them from connecting.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v9.1 LTS   9.1.0.8
    v9.2 LTS   9.2.0.2
    v9.x CD    9.2.2
    
    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

    IT34895

  • Reported component name

    MQ APPLIANCE M2

  • Reported component ID

    5737H4700

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-11-11

  • Closed date

    2021-01-27

  • Last modified date

    2021-01-27

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

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

Fix information

  • Fixed component name

    MQ APPLIANCE M2

  • Fixed component ID

    5737H4700

Applicable component levels

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SS5K6E","label":"IBM MQ Appliance"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]

Document Information

Modified date:
28 January 2021