[IBM i]

Example: planning a message channel on IBM i

A detailed example of how to connect two IBM® i queue managers together so that messages can be sent between them. The example involves a payroll query application connected to queue manager QM1 that sends payroll query messages to a payroll processing application running on queue manager QM2. The payroll query application needs the replies to its queries sent back to QM1.

About this task

The example illustrates the preparations needed to allow an application using queue manager QM1 to put messages on a queue at queue manager QM2. An application running on QM2 can retrieve these messages, and send responses to a reply queue on QM1.

The example illustrates the use of TCP/IP connections. The example assumes that channels are to be triggered to start when the first message arrives on the transmission queue they are servicing.

This example uses SYSTEM.CHANNEL.INITQ as the initiation queue. This queue is already defined by IBM MQ. You can use a different initiation queue, but you have to define it yourself, start a new instance of the channel initiator using the STRMQMCHLI command, and provide it with the name of your initiation queue. For more information about triggering channels, see Triggering channels.
[Continuous Delivery][IBM MQ Advanced]Note: A message channel that uses TCP/IP can be pointed at an IBM Aspera® faspio Gateway, which provides a fast TCP/IP tunnel that can significantly increase network throughput. See Defining an Aspera gateway connection on Linux® or Windows.
Figure 1. The message channel example for IBM MQ for IBM i
Refer to the text following this figure for a description of the components and the example configuration.

The payroll query messages are sent from QM1 to QM2 on a sender-receiver channel called QM1.TO.QM2, and the reply messages are sent back from QM2 to QM1 on another sender-receiver channel called QM2.TO.QM1. Both of these channels are triggered to start as soon as they have a message to send to the other queue manager.

The payroll query application puts a query message to the remote queue PAYROLL.QUERY defined on QM1. This remote queue definition resolves to the local queue PAYROLL on QM2. In addition, the payroll query application specifies that the reply to the query is sent to the local queue PAYROLL.REPLY on QM1. The payroll processing application gets messages from the local queue PAYROLL on QM2, and sends the replies to wherever they are required; in this case, local queue PAYROLL.REPLY on QM1.

Both queue managers are assumed to be running on IBM i. In the example definitions, QM1 has a host address of 192.0.2.0 and is listening on port 1411. QM2 has a host address of 192.0.2.1 and is listening on port 1412. The example assumes that these queue managers are already defined on your IBM i system, and are available for use.

The object definitions that need to be created on QM1 are:
  • Remote queue definition, PAYROLL.QUERY
  • Transmission queue definition, QM2 (default=remote queue manager name)
  • Sender channel definition, QM1.TO.QM2
  • Receiver channel definition, QM2.TO.QM1
  • Reply-to queue definition, PAYROLL.REPLY
The object definitions that need to be created on QM2 are:
  • Local queue definition, PAYROLL
  • Transmission queue definition, QM1 (default=remote queue manager name)
  • Sender channel definition, QM2.TO.QM1
  • Receiver channel definition, QM1.TO.QM2

The connection details are supplied in the CONNAME attribute of the sender channel definitions.

You can see a diagram of the arrangement in Figure 1.

Procedure

See: