Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Mar 19, 2015

Return RC from active QMgr in Multi-Instance environment

When attempting to connect to a multi-instance queue manager, if the client fails to connect to the first host it attempts to connect to the second host and returns a Reason Code based on the second attempt (i.e. RC=0 if successful, RC=2538 for Host Not Available).

If the queue manager is actually running on the first host, and the connection fails for some reason (i.e. RC=2035 Not Authorized, RC=2025 Max Conns Reached, etc..) the client tries the second host and returns RC=2538 because that host is running the standby instance.

The problems with this is that the client is led to believe that MQ is unavailable, not that they have a specific problem with their connection. Often the real reason code is not discovered until we do a client trace where we can see the reason code from the first connection attempt.

The change I would like is for the MQ client code to always favor returning a reason code that came from a running queue manager (i.e. RC=2035) over the reason code from the attempt to connect to the standby queue manager.

Idea priority High
RFE ID 68339
RFE Product IBM MQ
  • Guest
    Apr 11, 2017

    This requirement is understood and recognised. MQRC_HOST_NOT_AVAILABLE and MQRC_STANDBY_Q_MGR return codes should be superseded by any other non-zero failure return codes. This will be considered under for inclusion in a future MQ CD release.

  • Guest
    Oct 15, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - WebSphere
    Product family - Integration
    Product - IBM MQ

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Connectivity and Integration
    Product - IBM MQ