We recently upgraded our MQ server and client base images for our cloud deployments to 9.2.  We want to begin using the Uniform Cluster pattern.  This means switching our clients over to using CCDT files.  I'm reading through the documentation to understand the nuts and bolts and have a few general questions.  I was able to deploy a local 2-node cluster in Docker and have a simple set of pub/sub clients connecting to this through CCDT files (JSON format).  

• In setting up the cluster I gave each node's queue manager a different name (e.g., PQ1 and PQ2).  Is this necessary?  Seems all nodes in the cluster could have the same name for the queue manager.  The host/port portion of the connection would always identify a specific server.
• My test clients are written in NodeJS, using the mq-mqi-nodejs package.  When I set up the  connection I am able to specify the CCDT file location using the MQCNO.CCDTUrl parameter.  However, when calling Connx I also have to pass the queue manager name as a parameter.  Effectively, I'm passing the queue manager name twice -- once in CCDT file and once as a parameter.  Is this correct?  I thought the point of the CCDT was to specify a channel name object that contains everything necessary (including queue manager name) for a client to connect.
• The documentation shows an example of a CCDT JSON file with two channels defined with the same name, but different connection info and queue manager names.  What is the point of this illustration?  Is this a case where the queue manager name is needed to pick the connection?  Or, does the client just go down the list until it makes the connection?
• Since I'm setting up a uniform cluster should I care which node my client connects to?  In fact, if I specify a queue manager name when making the connection, and that specific server is in the process of restarting, then I would expect the connection to be picked up by the next available node.

Thanks in advance for your help.  
Jim

------------------------------
Jim Creasman
------------------------------

To answer your questions:-

• Yes, it is expected that every queue manager in a cluster has a unique name.
• You are not passing in a queue manager name when you are using a CCDT, you are passing in a string to use to search the CCDT with. For Uniform Clusters, your CCDT will be set up with each queue manager with it's own name, and then a each queue manager a second time with the group name instead of a queue manager name. This group name is what you should be passing in on the MQCONN(X).
• The documentation you refer to is illustrating the new JSON CCDT and one feature of JSON CCDT that is new over and above the original binary CCDT is that channels in the CCDT do not have to have unique names. Thus this documentation is showing off this feature since you can't do it with a binary CCDT. The queue manager name is always needed to pick the connection.
• The point of a UNIFORM cluster is that all the queue managers provide the same resources and you shouldn't care which member of the cluster your client connects to. If you specify a queue manager name rather than the CCDT group name, you are indicating that you explicitly want to connect to that queue manager. You could be using the group name to connect to.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Thanks, Morag.  I was missing the concepts of groups in the CCDT JSON files.  Once I added that and updated the Connx call to pass in a generic queue manager name it all worked.  

For others that may be looking at this another user sent me this link (https://community.ibm.com/community/user/communities/community-home/librarydocuments/viewdocument?DocumentKey=40471645-a0aa-4028-b2eb-f5211384ef32) which I found to be a good reference in understanding the nuts and bolts.

Jim

------------------------------
Jim Creasman
------------------------------

Original Message:
Sent: Tue June 15, 2021 06:59 PM
From: Morag Hughson
Subject: Uniform Clusters and CCDT

To answer your questions:-

• Yes, it is expected that every queue manager in a cluster has a unique name.
• You are not passing in a queue manager name when you are using a CCDT, you are passing in a string to use to search the CCDT with. For Uniform Clusters, your CCDT will be set up with each queue manager with it's own name, and then a each queue manager a second time with the group name instead of a queue manager name. This group name is what you should be passing in on the MQCONN(X).
• The documentation you refer to is illustrating the new JSON CCDT and one feature of JSON CCDT that is new over and above the original binary CCDT is that channels in the CCDT do not have to have unique names. Thus this documentation is showing off this feature since you can't do it with a binary CCDT. The queue manager name is always needed to pick the connection.
• The point of a UNIFORM cluster is that all the queue managers provide the same resources and you shouldn't care which member of the cluster your client connects to. If you specify a queue manager name rather than the CCDT group name, you are indicating that you explicitly want to connect to that queue manager. You could be using the group name to connect to.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Hi Jim,

One further thought on Morag's response if you haven't used group names in a CCDT before.

In you queue manager name in the MQCONNX, prefix the name with * (asterisk). That tells MQ to search the CCDT for a queue manager name values which is the string following the asterisk, but to not check that the actual queue manager matches the name. Otherwise when the client connects, it checks the actual queue manager name against the string from MQCONNX and fails because they are different.

Regards,

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
------------------------------