Example: planning a message channel on AIX, Linux, and Windows

This information provides a detailed example of how to connect two queue managers together so that messages can be sent between them.

About this task

In all the examples, the MQSC commands are shown as they would appear in a file of commands, and as they would be typed at the command line. The two methods look identical, but, to issue a command at the command line, you must first type runmqsc, for the default queue manager, or runmqsc qmname where qmname is the name of the required queue manager. Then type any number of commands, as shown in the examples.

An alternative method is to create a file containing these commands. Any errors in the commands are then easy to correct. If you called your file mqsc.in then to run it on queue manager QMNAME use:

runmqsc QMNAME < mqsc.in > mqsc.out

You could verify the commands in your file before running it using:

runmqsc -v QMNAME < mqsc.in > mqsc.out

For portability, you should restrict the line length of your commands to 72 characters. Use a concatenation character to continue over more than one line. On Windows use Ctrl-z to end the input at the command line. On AIX® and Linux® systems use Ctrl-d. Alternatively, use the end command.

Figure 1 shows the example scenario.

Refer to the text following this figure for a description of the figure, its components, and message flow. — Figure 1. The message channel example for AIX, Linux, and Windows systems

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

In the example definitions for TCP/IP, QM1 has a host address of 192.0.2.0 and is listening on port 1411, and QM2 has a host address of 192.0.2.1 and is listening on port 1412. The example assumes that these are already defined on your system and 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:

Setting up the message channel example for AIX, Linux, and Windows for details on setting up the message channels
Running and expanding the example for AIX, Linux, and Windows for suggestions on how you can use other products, for example CICS®, and how you can connect more applications and user exits.