[z/OS]

Planning 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 you 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 you 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 you are using multiple TCP stacks you can specify the LOCLADDR parameter on the channel definition, which specifies the IP Stack address to be used.

You 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 you 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, you 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

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

You can control which connections can connect to IBM MQ and the user ID, based on It is also possible to restrict client applications by ensuring that they supply a valid user ID and password (see Connection Authentication).

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

Monitoring 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 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. You can suppress these messages either by using the z/OS message processing facility, or by setting EXCLMSG with the SET SYSTEM command.

See Planning for channel initiator SMF data for more information.

Configuring your 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 you are planning to have a large number of queue managers in a cluster, you should plan to have queue managers that act as dedicated repositories and have no application traffic.

See Planning your distributed queues and clusters for more information.

Actions before you configure the channel initiator

  1. Decide if you are using TCP/IP or APPC.
  2. If you are using TCP, allocate at least one port for IBM MQ.
  3. If you need a a DNS server, configure the server to be highly available if required.
  4. If you 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 you 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 you need to use multiple TCP stacks, VIPA, or an external router for availability in front of the channel initiator.
  4. If you are planning on using TLS:
    1. Set up the key ring
    2. Set up certificates
  5. If you 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. You 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.