If there’s one thing we can say for definite it is that you should have a naming convention for your MQ object names. Beyond that point, there are no rules about what names you should choose (other than those provided by IBM MQ for length and allowed characters). However, there are many recommendations that will help you come up with your naming convention.
When designing the names of your queue objects, consider what it is you need a naming convention to tell you. One important piece of information is the ownership of the queue, which department, and perhaps which application suite it belongs to. So if you have acronyms for these departments or application groups, include these in the object names. The same kind of convention will also be helpful for any processes, namelists and other ancillary objects you define. Then, when something goes wrong, a queue is full for example, it is immediately apparent what department and application it belongs to, and also the possible impact of the problem.
Another consideration is to include a TEST and PROD marker on an object name, especially if there is any likelihood of overlap of connectivity with the systems at all
Some useful tips when putting together a naming convention:
- Use upper case object names
While MQ does allow you to have lower and mixed case names, life is simpler and easier to read if you stick to upper case names. There is no confusion on case, no requirement to remember to put quotation marks round the names in scripts, and no issues using any names across different platforms.
- Stick to numbers, letters and the dot character
While MQ does allow a few other punctuation characters, like %, avoiding all except the dot will leave you assured that no matter which platform you are on, and which security profiles you wish to use, it will always work.
- Avoid the dot in queue manager names
While the dot is fine in object names to separate up sections of the name, avoid using it in queue manager names, thus making your channel names more easy to understand.
- Always use the description field
You’re not saving any space by not using it. MQ will store 64 blank characters so use it, and aid your object documentation by explaining what the object is there for, right on the object!
- NEVER begin objects with SYSTEM
The namespace starting SYSTEM is reserved for use by IBM MQ. Who knows when a new version might use a name you’ve started using? Just don’t risk it. Keeps the security simpler as well.
- Keep queue manager names short
While you may have a whole 48 characters available from IBM MQ, you don’t have to use it all! Imagine what you’d like to have to type in at a console when starting, ending or administering queue managers, and stick to that length. Keeping to 9 or less characters helps with channels (see below).
- Include user name in dynamically created queues
Applications which create dynamic queues should follow the above guidelines, but additionally include the user name running the application in the generated name. This then allows an administrator to determine which instance of an application is, for example, not tidying up its dynamic queues properly. The generated name is kept unique by allowing the queue manager to complete the name you supply as a prefix, by adding a unique timestamp.
Additionally, when thinking about channel names:-
- Include both queue managers in a channel name
For channels that are point to point, you can have the luxury of naming both sending and receiving channels in the channel name. In general, stick with a de facto standard of have the sending queue manager first and then the receiving queue manager with a dot separator. Assuming you haven’t put any dots in your queue manager names, then there will only be one dot in the channel name and this will make it very clear which queue managers are connected by this channel. Remember that channel names are only up to 20 characters, hence the limitation suggested on queue manager names.
- At minimum include the receiving queue manager name in a channel name
If you use generic receivers, then having the sending queue manager name as part of the channel name is not useful. Where above having TO between the queue manager names doesn’t add anything, and removes a few precious characters, for generic receivers, you might consider a pattern that is TO.<QMgr‑name>, or alternatively, <QMgr‑name>.RCVR (where normally it would not be expected to add object types to the name).
- Include the cluster name in cluster channels
It is best practice to only ever use one cluster per channel name (avoiding the CLUSNL keyword on channels completely). This allows channels to be controlled independently for different clusters, thus ensuring that there is no reliance, or impact shared by clusters just because of a common channel. This best practice allows you to then add the cluster keyword to the channel name which means you have immediate awareness of which cluster is impacted when you see a channel having connectivity issues for example.
I hope these guidelines help you with designing the naming convention that suits your business and your MQ applications. A naming convention will help your business by:-
- making it easier to find objects
- allowing an understanding of the purpose of objects at a glance
- easing the creation of security profiles
- reducing errors caused by using the wrong resource
- allowing environments to be easily replicated
There is no single naming convention that everyone SHOULD use. But everyone should have a naming convention. If you want help sticking to your naming convention read “Following your naming convention”.
Great additional resources to read when considering your IBM MQ Naming Convention
- Wonderfully answered question by T.Rob on StackOverflow
- An old, but still valuable version of SupportPac MD01: MQSeries – Standards and conventions Version 1.0