Plan to install IBM MQ for z/OS

To install the IBM MQ product your hardware, and software environment must meet minimum requirement levels. You must also consider the national language features, communications protocols, and naming conventions to be used.

National language support

We can choose one of the following national languages for the IBM MQ operator messages and the IBM MQ operations and control panels (including the character sets used). Each language is identified by one of the following language letters:

C

Simplified Chinese

E

U.S. English (mixed case)

F

French

K

Japanese

U

U.S. English (uppercase)

The samples, IBM MQ commands, and utility control statements are available only in mixed case U.S. English.

Communications protocol and distributed queuing

The distributed queuing facility provided with the base product feature of IBM MQ can either use APPC (LU 6.2), TCP/IP from IBM, or any TCP product which supports the z/OS® Unix Sockets API. The distributed queuing facility is also known as the channel initiator and the mover.

You must perform the following tasks to enable distributed queuing:

• Choose which communications interface to use. This can be either, or both, of the following:
  • APPC (LU 6.2)
  • TCP/IP
• Customize the distributed queuing facility and define the IBM MQ objects required.
• Define access security.
• Set up your communications. This includes setting up your TCPIP.DATA data set if you are using TCP/IP, LU names, and side information if you are using APPC. This is described in Set up communication for z/OS .

Naming conventions

It is advisable to establish a set of naming conventions when planning your IBM MQ systems. The names you choose will probably be used on different platforms, so you should follow the convention for IBM MQ, not for the particular platform.

IBM 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.

For more information, see Rules for naming IBM MQ objects.

Choosing names for queue managers and queue sharing groups

Each queue manager and queue sharing group within a network must have a unique name. Do not use the same name for a queue manager and a queue sharing group. 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 dollar sign ($), number sign (#) or at sign (@); they must not start with a numeric character. Queue sharing group names that are less than four characters long are padded internally with at signs, so do not use names ending in the at sign.

The queue manager name is the same as the z/OS subsystem name. You might identify each subsystem as a queue manager by giving it the name QM xx (where xx is a unique identifier), or you might choose a naming convention like 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 might identify each queue sharing group by giving it the name QG xx (where xx is the unique identifier).

Choosing names for objects

Queues, processes, name lists, 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 IBM 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 namespace, 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 might call a queue for inquiries about the company payroll payroll_inquiry. The reply-to queue for responses to the inquiries might 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 might be prefixed by payroll_. We 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 was a shared queue, you might call it payroll_inquiry.shared.

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, the structure names are the IBM 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.

Use command prefix strings

Each instance of IBM MQ that you install must have its own command prefix string (CPF). We use the CPF to identify the z/OS subsystem that commands are intended for. It also identifies the z/OS subsystem from which messages sent to the console originate.

We can issue all MQSC commands from an authorized console by inserting the CPF before the command. If you enter commands through the system command input queue (for example, using CSQUTIL), or use the IBM MQ operations and control panels, we do not use the CPF.

To start a subsystem called CSQ1 with CPF that is ' +CSQ1 ', issue the command +CSQ1 START QMGR from the operator console (the space between the CPF and the command is optional).

The CPF also identifies the subsystem that is returning operator messages. The following example shows +CSQ1 as the CPF between the message number and the message text.

CSQ9022I +CSQ1 CSQNCDSP ' DISPLAY CMDSERV' NORMAL COMPLETION

See Defining command prefix strings (CPFs) for information about defining command prefix strings.