Plan your channel initiator

The channel initiator provides communications between queue managers, and runs in its own address space.

There are two types of connections:

1. Application connections to a queue manager over a network. These are known as client channels.
2. Queue manager to queue manager connections. These are known as MCA channels.

Listeners

A channel listener program listens for incoming network requests and starts the appropriate channel when that channel is needed. To process inbound connections the channel initiator needs at least one IBM MQ listener task configured. A listener can either be a TCP listener, or a LU 6.2 listener.

Each listener requires a TCP port or LU name. IBM MQ for Multiplatforms often uses TCP/IP port 1414 (the default).

Note that we can have more than one listener for each channel initiator.

TCP/IP

A channel initiator can operate with more than one TCP stack on the same z/OS image. For example, one TCP stack could be for internal connections, and another TCP stack for external connections.

When you define an output channel:

1. You set the destination host and port of the connection. This can be either:
   • an IP address, for example 10.20.4.6
   • a host name, for example mvs-prod.myorg.com

   If we use a host name to specify the destination, IBM MQ uses the Domain Name System (DNS) to resolve the IP address of the destination.

2. If we are using multiple TCP stacks we can specify the LOCLADDR parameter on the channel definition, which specifies the IP Stack address to be used.

We should plan to have a highly available DNS server, or DNS servers. If the DNS is not available, outbound channels might not be able to start, and channel authentication rules that map an incoming connection using a host name cannot be processed.

APPC and LU 6.2

If we are using APPC, the channel initiator needs an LU name, and configuration in APPC.

Queue sharing groups

To provide a single system image, and allow an incoming IBM MQ connection request to go to any queue manager in the queue sharing group, we need to do some configuration. For example:

1. A hardware network router. This router has one IP address seen by the enterprise, and can route the initial request to any queue manager connected to this hardware.
2. A Virtual IP address (VIPA). An enterprise wide IP address is specified, and that address can be routed to any one of the TCP stacks in a sysplex. The TCP stack can then route it to any listening queue manager in the sysplex.

Protecting IBM MQ traffic

We can configure IBM MQ to use TLS (or SSL) connections to protect data on the wire. To use TLS you need to use digital certificates and key rings.

You also need to work with the personnel at the remote end of the channel, to ensure that you have compatible IBM MQ definitions and compatible certificates.

We can control which connections can connect to IBM MQ and the user ID, based on

• IP address
• Client user ID
• Remote queue manager, or
• Digital certificate (see Channel Authentication Records)

It is also possible to restrict client applications by ensuring that they supply a valid user ID and password (see Connection Authentication).

We can get the channel initiator working, and then configure each channel to use TLS, one at a time.

Monitor the channel initiator

There are MQSC commands that give information about the channel initiator and channels:

• The DISPLAY CHINIT command gives information about the channel initiator, and active listeners.
• The DISPLAY CHSTATUS command displays the activity and status of a channel.

The channel initiator can also produce SMF records with information about the channel initiator tasks and channel activity. See Plan for channel initiator SMF data for more information.

The channel initiator emits messages to the job log when channels start and stop. Automation in your enterprise can use these messages to capture status. As some channels are active for only a few seconds, many messages can be produced. We can suppress these messages either by using the z/OS message processing facility, or by setting EXCLMSG with the SET SYSTEM command.

Configure the IBM MQ channel definitions

When you have many queue managers connected together it can be hard to manage all the object definitions. Using IBM MQ clustering can simplify this.

You specify two queue managers as full repositories. Other queue managers need one connection to, and one connection from, one of the repositories. When connections to other queue managers are needed, the queue manager creates and starts channels automatically.

If we are planning to have a large number of queue managers in a cluster, we should plan to have queue managers that act as dedicated repositories and have no application traffic.

See Plan for distributed queues and clusters for more information.

Actions before you configure the channel initiator

1. Decide if we are using TCP/IP or APPC.
2. If we are using TCP, allocate at least one port for IBM MQ.
3. For a a DNS server, configure the server to be highly available if required.
4. If we are using APPC, allocate an LU name, and configure APPC.

Actions after you have configured the channel initiator, before you go into production

1. Plan what connections we will have:
   1. Client connections from remote applications.
   2. MCA channels to and from other queue managers. Typically you have a channel to and from each remote queue manager.

2. Set up clustering, or join an existing clustering environment.
3. Consider whether we need to use multiple TCP stacks, VIPA, or an external router for availability in front of the channel initiator.
4. If we are planning on using TLS:
   1. Set up the key ring
   2. Set up certificates

5. If we are planning on using channel authentication:
   1. Decide the criteria for mapping inbound sessions to MCA user IDs
   2. Enable reverse DNS lookup by setting the queue manager parameter REVDNS
   3. Review security. For example, delete the default channels, and specify user IDs with only the necessary authority in the MCAUSER attribute for a channel.

6. Capture the accounting and statistics SMF records produced by the channel initiator and post process them.
7. Automate the monitoring of job log messages.
8. If necessary, tune your network environment to improve throughput. With TCP, large send and receive buffers improve throughput. We can force MQ to use specific TCP buffer sizes using the commands:

   RECOVER QMGR(TUNE CHINTCPRBDYNSZ nnnnn)   
   RECOVER QMGR(TUNE CHINTCPSBDYNSZ nnnnn)

   which sets the SO_RCVBUF, and SO_SNDBUF, for the channels to the size in bytes specified in nnnnn.

• Plan for channel initiator SMF data
  We need to plan the implementation of collecting SMF data for the channel initiator.
• Plan your z/OS TCP/IP environment
  To get the best throughput through your network, we must use TCP/IP send and receive buffers with a size of 64 KB, or greater. With this size, the system optimizes its buffer sizes.

Parent topic: Plan the IBM MQ environment on z/OS

Related concepts

• Plan for the queue manager