Naming conventions
It is advisable to establish a set of naming conventions when planning your WebSphere MQ systems. The names you choose will probably be used on different platforms, so you should follow the convention for WebSphere MQ, not for the particular platform.
WebSphere MQ allows both uppercase and lowercase letters in names, and the names are case sensitive. However, some z/OS consoles fold names to uppercase, so do not use lowercase letters for names unless you are sure that this will not happen.
We can also use numeric characters and the period (.), forward slash (/), underscore (_) and percent (%) characters. The percent sign is a special character to Security Server (previously known as RACF), so do not use it in names if you are using Security Server as your External Security Manager. Do not use leading or trailing underscore characters if you are planning to use the Operations and Control panels.
Rules for naming WebSphere MQ objects are described in the WebSphere MQ Script (MQSC) Command Reference manual.
Choosing names for queue managers and queue-sharing groups
Each queue manager and queue-sharing group within a network must have a unique name. On z/OS the names of queue managers and queue-sharing groups can be up to four characters long. Each DB2 system and data-sharing group within the network must also have a unique name.
The names of queue manager and queue-sharing groups can use only uppercase alphabetic characters, numeric characters, and $, # or @; they must not start with a numeric character. Queue-sharing group names that are less than four characters long are padded internally with @ symbols, so do not use names ending in @.
The queue manager name is the same as the z/OS subsystem name. You could identify each subsystem as a queue manager by giving it the name
QMxx (where xx is a unique identifier), or you could choose a naming convention similar to
ADDX, where A signifies the geographic area, DD signifies the company division, and
X is a unique identifier.
You might want to use your naming convention to distinguish between queue managers and queue-sharing groups. For example, you could identify each queue-sharing group by giving it the name
QGxx (where xx is the unique identifier).
Choosing names for objects
Queues, processes, namelists, and clusters can have names up to 48 characters long. Channels can have names up to 20 characters long and storage classes can have names up to 8 characters long.
If possible, choose meaningful names within any constraints of your local conventions. Any structure or hierarchy within names is ignored by WebSphere MQ, however, hierarchical names can be useful for system management. We can also specify a description of the object when you define it to give more information about its purpose.
Each object must have a unique name within its object type. However, each object type has a separate name space, so we can define objects of different types with the same name. For example, if a queue has an associated process definition, it is a good idea to give the queue and the process the same name. It is also a good idea to give a transmission queue the same name as its destination queue manager.
You could also use the naming convention to identify whether the object definition is private or a global. For example, you could call a namelist
project_group.global to indicate that the definition is stored on the shared repository.
Application queues
Choosing names that describe the function of each queue helps you to manage these queues more easily. For example, you could call a queue for inquiries about the company payroll
payroll_inquiry. The reply-to queue for responses to the inquiries could be called
payroll_inquiry_reply.
We can use a prefix to group related queues. This means that we can specify groups of queues for administration tasks like managing security and using the dead-letter queue handler. For example, all the queues that belong to the payroll application could be prefixed by
payroll_. You can then define a single security profile to protect all queues with names beginning with this prefix.
We can also use your naming convention to indicate that a queue is a shared queue. For example, if the payroll inquiry queue mentioned above was a shared queue, you could call it
Storage classes and Coupling Facility structures
The character set we can use when naming storage classes and Coupling Facility structures is limited to uppercase alphabetic and numeric characters. You should be systematic when choosing names for these objects.
Storage class names can be up to 8 characters long, and must begin with an alphabetic character. You will probably not define many storage classes, so a simple name is sufficient. For example, a storage class for IMS bridge queues could be called
IMS.
Coupling Facility structure names can be up to 12 characters long, and must begin with an alphabetic character. You could use the name to indicate something about the shared queues associated with the Coupling Facility structure (that they all belong to one suite of applications for example). Remember that in the Coupling Facility itself, the structure names are the WebSphere MQ name prefixed by the name of the queue-sharing group (padded to four characters with @ symbols).
Choosing names for channels
To help you manage channels, it is a good idea if the channel name includes the names of the source and target queue managers. For example, a channel transmitting messages from a queue manager called QM27 to a queue manager called QM11 might be called
QM27/QM11.
If your network supports both TCP and SNA, you might also want to include the transport type in the channel name, for example
QM27/QM11_TCP. You could also indicate whether the channel is a shared channel, for example
QM27/QM11_TCP.shared.
Remember that channel names cannot be longer than 20 characters. If you are communicating with a queue manager on a different platform, where the name of the queue manager might contain more than 4 characters, you might not be able to include the whole name in the name of the channel.