Want to move to CCDTs for your existing client applications but don't want to have to make code changes? No problem.
A lot of the coolest new features in recent MQ releases either require or become much more powerful when your client applications connect via a CCDT (Client Channel Definition Table). CCDTs contain a list of queue manager 'endpoints' and therefore decouple the application from connecting to a specific queue manager, allowing you to connect to queue manager 'groups' and enabling features like connection balancing, HA failover, and even automatic rebalancing in Uniform Clusters.
Using a CCDT for your application can be pretty simple - there are a variety of ways to supply it to the MQ client libraries - via an environment variable, in your application code, pointing to a remote URL - but most of the above use cases do have one common requirement of the application code - we need it NOT to have hard coded in the queue manager name. Otherwise, whatever entries are available in your CCDT, and however we choose between them, when it comes to actually make the MQCONN to the resolved queue manager this is going to fail with MQRC_Q_MGR_NAME_ERROR.
If your applications already make the QMName configurable (e.g. read from a config file, or passed in as an argument) then you have no problem! Unfortunately, hard-coding the Queue Manager name in this manner used to be pretty common practice in MQ application development (hopefully not any more - if you're still doing this, stop right now!) As we know, any change that requires going back to an app dev team to update the code and rebuild applications - even assuming they can still find the source - isn't likely to be popular! And any resistance there means it's harder to take advantage of these features and all the benefits they can bring.
The good news is that there are several ways you can work around this problem. The simplest case is if these are Java client applications, written using the MQ Classes for Java or MQ Classes for JMS. For these application types it is possible to override the queue manager name using a 'connection property override' (for JMS applications using JNDI objects to manage connections, it may be even simpler and purely a JNDI administration step).
For MQI (e.g. C) applications, unfortunately there is no 'no code' way to override the queue manager name if the application has hard coded it. However, it is very simple to achieve the same thing using a Client Preconnect Exit - a small snippet of code executed immediately before the MQ library calls MQCONN. This is such a common requirement that I've put together a very simple sample here on the ibm-messaging github repository - this allows you to override the QMName with any string of your choice (or '*' if nothing else is provided). Simply build the sample and drop into your client installation exits directory, and update mqclient.ini as shown to get going.
(This really is about the simplest exit possible - the 'meat' of the function is only about 4 lines of C code! Of course much more is possible in a preconnect exit - for example amqlcelp provided as a sample in the MQ product installation shows a much more advanced usage in which the exit is used to fetch entire CCDTs from an LDAP server.)
If this was the blocker to YOU moving forward with CCDTs - and opening up a bunch of new possibilities to your older MQ client applications - I hope this is what you need to get past that hurdle and move on to the good stuff!