It is well know to some of us that clients coming into a QSG using a shared listener is expensive because it updates DB2 status information.
One option is to set up a TCP generic port for just for clients. You define a listener for this port on each queue manager. You can do this by defining the listener on each queue manager, or defining it once specifying QSGDISP(GROUP).
I suggested this to one customer who said ' good plan - but we are not allowed to use an additional port'. OK - time for plans b), c) and d).
Plan B. At the client you can specify a list of connections. If the first address is not available, it will use the next. This gives better availability - but most of your connections will go to the first queue manager in the list.
Plan C. Use a Client Channel Definition Table (CCDT). You can create it on z/OS or distributed, and download it to the client machine.
You can specify the channel option CLNTWGHT. This will influence which queue manager is selected. Over a large number of connections you should be able to get workload distribution. This solution is good - because it gives higher availability by providing a list of queue managers, and it helps with reliability because it can spread the workload across multiple instances - but if you want to change the CCDT - you have to update the CCDT and download it to each client machine.
Plan D. In V9 you can specify an network address using MQCCDTURL , and the client code will download the CCDT from the network for example using FTP See here for more detail.
You change the CCDT in one place on the network, and it will get downloaded then next time the client starts.