This sounds like a good topic for the new Mission: Messaging column, but I will write a condensed version here. I will provide my answer, noting that many of my recommendations are contrary to those that you can find elsewhere. In some cases, this is because the way you use MQ has usually changed over the years. In other cases, this is because traditional wisdom never worked. (For example, cluster channels named TO.QMGR .) In all cases, I prefer conventions that apply to the largest number of situations. This means that you can usually find exceptions for these rules for specific cases, but they are generally applicable nonetheless.
Some general rules
The following applies to all types of objects.
Use a dot symbol . as a separator.
Authorization rules parse names using dotted characters as delimiters. For example, the queue name MY.EXAMPLE.QUEUE.NAME will follow rules such as MY.*.*.* Or MY.** , but not MY.* , Because the dots indicate the symbolic characters of node. Do yourself a favor and use periods, not underscores, as node separators.
Use names recognized by the machine.
When you have 5 queue managers and several hundred objects, you can easily get it by doing all your manual management using WMQ Explorer or runmqsc. However, there comes a time when consistency, reliability, repeatability and efficiency require that you script execute some of your usual operations or use tools to respond to network events. Moreover, this means eliminating ambiguity in names.
For example, if you create a naming convention, the channel names should look like SRCQMGR.DESTQMGR , then it is possible for the script to read the channel name RCVR or SDR and RCVR names of the two manager queues to which it connects. However, what does the script do with the name of the channel, for example GA.PAYROLL.OPS ? Is the GA.PAYROLL queue GA.PAYROLL connected to the OPS queue manager? Or is the GA queue manager connecting to the PAYROLL.OPS queue PAYROLL.OPS ? A person can tell instantly based on context, but the scenarios are notorious for what you tell them and not for what you intended. Similar situations arise when queue names have position-specific qualifiers both at the beginning and at the end of the name and in a variable number of nodes.
Stick to UPPERCASE names.
This applies to compatibility on all platforms, and in particular z / OS. Although it is true that other z / OS stores use a mixed case, it is also true that there are still many systems that accept only UPPERCASE names. Although it’s easy to say that “this does not apply to me,” I have seen many cases where someone had problems with a new business partner due to incompatible names. In the end, the ability to interact with almost any platform there is one of the main reasons for using WMQ in the first place.
Do not include object attributes in the name
In the SOA world, queues and topics are different types of assignment and are often interchangeable. Something that puts messages in what he thinks is the queue, it is not necessary to know (or care!) If they really go to the queue or topic. A queue in which an application that listens to it for messages can be downloaded by an administrative subscription, which is actually loaded into a publication from one or more topics.
We really care about the nature of the messages — what function they perform, and not about whether we are connecting to a local queue or an alias queue. Therefore, the addition of classifiers such as .QA , .QL , .TPC (for the topic), etc. It makes no sense. Similarly, adding .RCVR to the channel name sucks in 5 useful characters that could be better used when describing the name QMgr. Even worse, these methods bake the topology in the names of objects, making the system less flexible and more fragile.
Channel names
Point-to-Point Channel Names
Use names such as SRCQMGR.DESTQMGR for the RCVR , RQSTR , SDR and SVR channels. This prejudice applies to languages that are read from left to right, because the goal is to describe the data flow from QMgr to another QMgr
Cluster channels
Use names like CLUSNAME.QMNAME . Old wisdom stated that it uses names like TO.QMNAME , but if you ever implement overlapping clusters, this leads to the fact that the same channel will be used for several clusters. This is bad because you can never perform maintenance on one cluster without affecting another. Using CLUSNAME.QMNAME ensures that each QMgr has a dedicated CLUSRCVR channel for each cluster in which it participates.
Client channels
The exception to “do not include the attributes of the object in the name” is perhaps the SVRCONN channel. This is due to the fact that channels are very attached to the physical, and not to the logical level of the network. Thus, placing the QMgr name in the SVRCONN channel name is usually good. I don't mind too much if people want to add .SVRCONN to the end.
What you need to remember about client channels is that if you use the client channel definition table (CCDT), then the channel name is a unique index on this table. This means that you cannot have the same channel name on multiple QMgr and use CCDT. Since CCDT is one way to configure SSL / TLS channel information, this is often not fully evaluated until the project "finally let secure WMQ" appears. Using unique channel names for SVRCONN channels from the very beginning, you can reliably protect your network. Usually these names look like APP.QMNAME or in order to make it obvious that you are not dealing with a cluster or a point-to-point channel, APP.QMNAME.SVRCONN or similar.
Names of queue managers
No dots in QMgr names
One of the consequences of the previous rules is that the names of the cluster and queue managers must contain only one node and therefore must never contain a character . . This is because channel names are usually inferred from cluster names and / or QMgr. Thus, in the above example, the RCVR channel RCVR , such as GA_PAYROLL.OPS , would tell both people and scripts that this channel associates QMgr with the name GA_PAYROLL with QMgr with the name OPS .
Names 9 characters or less
Channel names can be just 20 characters. Subtract one for the point separator, divide it into two and round down to get up to 9 characters for the queue managers. If it is possible that you can configure different channels for service classes (for example, for large or small messages, then return 8 characters or less for QMgr names. This results in QM1.QM2.A , QM1.QM2.B , etc. .
QMgr names reflect physical layer
In a service-oriented world, we really like assignment names such as queues and topics. We pay much less attention to the names of queue managers, because this is just life support for queues and topics. Client applications don't care what QMgr connects to if they can send requests and receive responses. WMQ very conveniently fills the QMgr response name for outgoing requests, so it rarely happens that an application needs to know about it.
On the other hand, administrators should be aware of the name QMgr. In the early days, it was customary to call QMgrs for the host server. Later it became a fashion to name them for the applications they hosted. Now in the SOA world, messaging is an infrastructure and is usually not associated with any application, so the pendulum leaned back. Give QMgr a unique name that makes sense to the administrator.
Never reuse QMgr names!
Unfortunately, it’s very common to “move” QMgr from one place to another or have QMgr with initial and disaster recovery with the same name. This practice usually means that some part of the application depends on the name of QMgr, and therefore it is "easier" to reuse the name. IBM introduced QMID as a way to solve some of the problems that arise when reusing QMgr names. A typical use case is that node is being restored, and QMgr is being restored again from scratch. The cluster knows that this is the new QMgr, because the QMID has changed, but the name used for routing and other operations remains the same.
Although this has helped in limited use, it does not address the issue when both QMgr with the same name are simultaneously online. Nor does it address the issue that a reputable certificate authority will not issue multiple certificates with the same distinguished name, which forces you to reuse the same certificate for multiple QMgrs.
Remember that QMgrs is just life support for queues and topics, and ideally will be anonymous for applications that use them. Choose a naming convention that allows you to deploy new QMgrs with hundreds or thousands of unique names if you need to not have to reuse QMgr names.
Other objects
Use intent ads
Or, to put it another way, call an object what it does, not what it is. For example, if you had the habit (like so many people) of including classifiers such as .QL for local queues and .QA for aliases, then any change in topology will affect applications that use these queues. Instead, specify the queues for the functions that they represent.
Go left-right, the most common for the most specific
Names of objects, especially queues, must be hierarchically constructed, starting with the most general classifier and passing to the most specific classifier. For example, many stores use APP.FUNC.SUBFUNC.VER , where APP is the identifier of the owner application, then one or more nodes with a function and subfunction. Many stores add a version specifier at the end so that new versions of the service can transfer their customers to separate schedules, and not change the service in the existing queue and simultaneously change all customers.
What reads messages belongs to the queue
If I have a service endpoint represented by a queue, then there is a relationship between things that can be called by the service that provides the service. The queue is associated with the service and the service that provides this service. Customers are more or less anonymous. Therefore, if any of the stakeholder applications can say that he "owns" the queue, this service provider application, which consumes messages, forms it.
What posts the post belongs to the topic. View.
Relations are not so straightforward with topics. Here, message consumers are usually anonymous. In this sense, if the title of the topic reflects any application, it is most likely the publisher. However, even publishers may be anonymous, or at least many of them and not all publications at the same time. Using it all the more important is that the nodes of the topic tree are structured for the hierarchy of data or the functionality that they represent. As a rule, these names correspond to the names of publishing applications; therefore, the publisher "owns" this topic as incompatible as everything else.
Place positional qualifying commands on the left. If the names have a variable number of qualifiers, place positional qualifying commands on the left, where scripts and automation can analyze them. In some stores, where both the start and end qualifiers position a deal with this, using underscores for separators in the variable section of a name type APP.FUNC.SUBFUNC1_SUBFUNC2.VER . Scripts and authorizations always see a fixed number of nodes in a name, but this approach can be fragile if someone forgets and makes a name with an additional node or two.
additional literature
This sums up most of the general rules, but some of them are in the Mission: Messages column. In particular: