Set up a new cluster

Follow these instructions to set up the example cluster. Separate instructions describe setting up the cluster on TCP/IP, LU 6.2, and with a single transmission queue or multiple transmission queues. Test the cluster works by sending a message from one queue manager to the other.


Before starting

  • Instead of following these instructions, we can use one of the wizards supplied with IBM MQ Explorer to create a cluster like the one created by this task. Right-click the Queue Manager Clusters folder, then click New > Queue Manager Cluster, and follow the instructions given in the wizard.
  • For background information to aid your understanding of the steps taken to set up a cluster, see Defining cluster queues, Cluster channels and Listeners.


You are setting up a new IBM MQ network for a chain store. The store has two branches, one in London and one in New York. The data and applications for each store are hosted by systems running separate queue managers. The two queue managers are called LONDON and NEWYORK. The inventory application runs on the system in New York, connected to queue manager NEWYORK. The application is driven by the arrival of messages on the INVENTQ queue, hosted by NEWYORK. The two queue managers, LONDON and NEWYORK, are to be linked in a cluster called INVENTORY so that they can both put messages to the INVENTQ.

Figure 1 shows what this cluster looks like.

Figure 1. The INVENTORY cluster with two queue managers

We can configure each queue manager in the cluster to send messages to other queue managers in the cluster using different cluster transmission queues.

The instructions to set up the cluster vary a little by transport protocol, number of transmission queues, or platform. We have a choice of three combinations. The verification procedure remains the same for all combinations.


Procedure


Results

Figure 1 shows the INVENTORY cluster set up by this task.

Clearly, INVENTORY is a small cluster. However, it is useful as a proof of concept. The important thing to understand about this cluster is the scope it offers for future enhancement.

Parent topic: Configure a queue manager cluster


Related tasks


Related information


Set up a cluster using TCP/IP with a single transmission queue per queue manager


Before starting

  • The queue manager attribute, DEFCLXQ, must be left as its default value, SCTQ.


About this task

Follow these steps to set up a cluster on Multiplatforms using the transport protocol TCP/IP. On z/OS, we must follow the instructions in Defining a TCP connection on z/OS to set up the TCP/IP connection, rather than defining the listeners in step 4. Otherwise, the steps are the same for z/OS, but error messages are written to the console, rather than to the queue manager error log.


Procedure

  1. Decide on the organization of the cluster and its name.

    You decided to link the two queue managers, LONDON and NEWYORK, into a cluster. A cluster with only two queue managers offers only marginal benefit over a network that is to use distributed queuing. It is a good way to start and it provides scope for future expansion. When you open new branches of our store, we are able to add the new queue managers to the cluster easily. Adding new queue managers does not disrupt the existing network; see Adding a queue manager to a cluster.

    For the time being, the only application we are running is the inventory application. The cluster name is INVENTORY.

  2. Decide which queue managers are to hold full repositories.

    In any cluster we must nominate at least one queue manager, or preferably two, to hold full repositories. In this example, there are only two queue managers, LONDON and NEWYORK, both of which hold full repositories.

    1. We can perform the remaining steps in any order.
    2. As you proceed through the steps, warning messages might be written to the queue manager log. The messages are a result of missing definitions that we have yet to add. 
      Examples of the responses to the commands are shown in a box
like this after each step in this task.
These examples show the responses returned by IBM MQ for AIX.
The responses vary on other platforms.
    3. Before proceeding with these steps, make sure that the queue managers are started.

  3. Alter the queue manager definitions to add repository definitions. On each queue manager that is to hold a full repository, alter the local queue manager definition, using the ALTER QMGR command and specifying the REPOS attribute: 
    ALTER QMGR REPOS(INVENTORY)

    1 : ALTER QMGR REPOS(INVENTORY)
AMQ8005: WebSphere MQ queue manager changed.
    For example, if you enter:
    1. runmqsc LONDON
    2. ALTER QMGR REPOS(INVENTORY)

    LONDON is changed to a full repository.

  4. Define the listeners.

    Define a listener that accepts network requests from other queue managers for every queue manager in the cluster. On the LONDON queue managers, issue the following command: 

    DEFINE LISTENER(LONDON_LS) TRPTYPE(TCP) CONTROL(QMGR)
    The CONTROL attribute ensures that the listener starts and stops when the queue manager does. The listener is not started when it is defined, so it must be manually started the first time with the following MQSC command: 
    START LISTENER(LONDON_LS)
    Issue similar commands for all the other queue managers in the cluster, changing the listener name for each one.

    There are several ways to define these listeners, as shown in Listeners.

  5. Define the CLUSRCVR channel for the LONDON queue manager.

    On every queue manager in a cluster, you define a cluster-receiver channel on which the queue manager can receive messages. See Cluster-receiver channel: CLUSRCVR . The CLUSRCVR channel defines the connection name of the queue manager. The connection name is stored in the repositories, where other queue managers can refer to it. The CLUSTER keyword shows the availability of the queue manager to receive messages from other queue managers in the cluster.

    In this example the channel name is INVENTORY.LONDON, and the connection name (CONNAME) is the network address of the machine the queue manager resides on, which is LONDON.CHSTORE.COM. The network address can be entered as an alphanumeric DNS host name, or an IP address in either in IPv4 dotted decimal form. For example, 192.0.2.0, or IPv6 hexadecimal form; for example 2001:DB8:0204:acff:fe97:2c34:fde0:3485. The port number is not specified, so the default port (1414) is used. 

    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager LONDON')

    1 : DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager LONDON')
AMQ8014: WebSphere MQ channel created.
07/09/98 12:56:35 No repositories for cluster 'INVENTORY'
  6. Define the CLUSRCVR channel for the NEWYORK queue manager. If the channel listener is using the default port, typically 1414, and the cluster does not include a queue manager on z/OS, we can omit the CONNAME 
    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager NEWYORK')
  7. Define the CLUSSDR channel on the LONDON queue manager.

    You manually define a CLUSSDR channel from every full repository queue manager to every other full repository queue manager in the cluster. See Cluster-sender channel: CLUSSDR . In this case, there are only two queue managers, both of which hold full repositories. They each need a manually-defined CLUSSDR channel that points to the CLUSRCVR channel defined at the other queue manager. The channel names given on the CLUSSDR definitions must match the channel names on the corresponding CLUSRCVR definitions. When a queue manager has definitions for both a cluster-receiver channel and a cluster-sender channel in the same cluster, the cluster-sender channel is started. 

    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from LONDON to repository at NEWYORK')

    1 : DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from LONDON to repository at NEWYORK')
AMQ8014: WebSphere MQ channel created.
07/09/98 13:00:18  Channel program started.
  8. Define the CLUSSDR channel on the NEWYORK queue manager. 
    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from NEWYORK to repository at LONDON')
  9. Define the cluster queue INVENTQ Define the INVENTQ queue on the NEWYORK queue manager, specifying the CLUSTER keyword. 
    DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

    1 : DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)
AMQ8006: WebSphere MQ queue created.

    The CLUSTER keyword causes the queue to be advertised to the cluster. As soon as the queue is defined it becomes available to the other queue managers in the cluster. They can send messages to it without having to make a remote-queue definition for it.

    All the definitions are complete. On all platforms, start a listener program on each queue manager. The listener program waits for incoming network requests and starts the cluster-receiver channel when it is needed.


Set up a cluster on TCP/IP using multiple transmission queues per queue manager


About this task

Follow these steps to set up a cluster on Multiplatforms using the transport protocol TCP/IP. The repository queue managers are configured to use a different cluster transmission queue to send messages to each other, and to other queue managers in the cluster. If you add queue managers to the cluster that are also to use different transmission queues, follow the task, Adding a queue manager to a cluster: separate transmission queues.


Procedure

  1. Decide on the organization of the cluster and its name.

    You decided to link the two queue managers, LONDON and NEWYORK, into a cluster. A cluster with only two queue managers offers only marginal benefit over a network that is to use distributed queuing. It is a good way to start and it provides scope for future expansion. When you open new branches of our store, we are able to add the new queue managers to the cluster easily. Adding new queue managers does not disrupt the existing network; see Adding a queue manager to a cluster.

    For the time being, the only application we are running is the inventory application. The cluster name is INVENTORY.

  2. Decide which queue managers are to hold full repositories.

    In any cluster we must nominate at least one queue manager, or preferably two, to hold full repositories. In this example, there are only two queue managers, LONDON and NEWYORK, both of which hold full repositories.

    1. We can perform the remaining steps in any order.
    2. As you proceed through the steps, warning messages might be written to the queue manager log. The messages are a result of missing definitions that we have yet to add. 
      Examples of the responses to the commands are shown in a box
like this after each step in this task.
These examples show the responses returned by IBM MQ for AIX.
The responses vary on other platforms.
    3. Before proceeding with these steps, make sure that the queue managers are started.

  3. Alter the queue manager definitions to add repository definitions. On each queue manager that is to hold a full repository, alter the local queue manager definition, using the ALTER QMGR command and specifying the REPOS attribute: 
    ALTER QMGR REPOS(INVENTORY)

    1 : ALTER QMGR REPOS(INVENTORY)
AMQ8005: WebSphere MQ queue manager changed.
    For example, if you enter:
    1. runmqsc LONDON
    2. ALTER QMGR REPOS(INVENTORY)

    LONDON is changed to a full repository.

  4. Alter the queue manager definitions to create separate cluster transmission queues for each destination. 
    ALTER QMGR DEFCLXQ(CHANNEL)

    On each queue manager that you add to the cluster decide whether to use separate transmission queues or not. See the topics, Adding a queue manager to a cluster and Adding a queue manager to a cluster: separate transmission queues.

  5. Define the listeners.

    Define a listener that accepts network requests from other queue managers for every queue manager in the cluster. On the LONDON queue managers, issue the following command: 

    DEFINE LISTENER(LONDON_LS) TRPTYPE(TCP) CONTROL(QMGR)
    The CONTROL attribute ensures that the listener starts and stops when the queue manager does. The listener is not started when it is defined, so it must be manually started the first time with the following MQSC command: 
    START LISTENER(LONDON_LS)
    Issue similar commands for all the other queue managers in the cluster, changing the listener name for each one.

    There are several ways to define these listeners, as shown in Listeners.

  6. Define the CLUSRCVR channel for the LONDON queue manager.

    On every queue manager in a cluster, you define a cluster-receiver channel on which the queue manager can receive messages. See Cluster-receiver channel: CLUSRCVR . The CLUSRCVR channel defines the connection name of the queue manager. The connection name is stored in the repositories, where other queue managers can refer to it. The CLUSTER keyword shows the availability of the queue manager to receive messages from other queue managers in the cluster.

    In this example the channel name is INVENTORY.LONDON, and the connection name (CONNAME) is the network address of the machine the queue manager resides on, which is LONDON.CHSTORE.COM. The network address can be entered as an alphanumeric DNS host name, or an IP address in either in IPv4 dotted decimal form. For example, 192.0.2.0, or IPv6 hexadecimal form; for example 2001:DB8:0204:acff:fe97:2c34:fde0:3485. The port number is not specified, so the default port (1414) is used. 

    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager LONDON')

    1 : DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager LONDON')
AMQ8014: WebSphere MQ channel created.
07/09/98 12:56:35 No repositories for cluster 'INVENTORY'
  7. Define the CLUSRCVR channel for the NEWYORK queue manager. If the channel listener is using the default port, typically 1414, and the cluster does not include a queue manager on z/OS, we can omit the CONNAME 
    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager NEWYORK')
  8. Define the CLUSSDR channel on the LONDON queue manager.

    You manually define a CLUSSDR channel from every full repository queue manager to every other full repository queue manager in the cluster. See Cluster-sender channel: CLUSSDR . In this case, there are only two queue managers, both of which hold full repositories. They each need a manually-defined CLUSSDR channel that points to the CLUSRCVR channel defined at the other queue manager. The channel names given on the CLUSSDR definitions must match the channel names on the corresponding CLUSRCVR definitions. When a queue manager has definitions for both a cluster-receiver channel and a cluster-sender channel in the same cluster, the cluster-sender channel is started. 

    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from LONDON to repository at NEWYORK')

    1 : DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from LONDON to repository at NEWYORK')
AMQ8014: WebSphere MQ channel created.
07/09/98 13:00:18  Channel program started.
  9. Define the CLUSSDR channel on the NEWYORK queue manager. 
    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from NEWYORK to repository at LONDON')
  10. Define the cluster queue INVENTQ Define the INVENTQ queue on the NEWYORK queue manager, specifying the CLUSTER keyword. 
    DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

    1 : DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)
AMQ8006: WebSphere MQ queue created.

    The CLUSTER keyword causes the queue to be advertised to the cluster. As soon as the queue is defined it becomes available to the other queue managers in the cluster. They can send messages to it without having to make a remote-queue definition for it.

    All the definitions are complete. On all platforms, start a listener program on each queue manager. The listener program waits for incoming network requests and starts the cluster-receiver channel when it is needed.


Set up a cluster using LU 6.2 on z/OS


Procedure

  1. Decide on the organization of the cluster and its name.

    You decided to link the two queue managers, LONDON and NEWYORK, into a cluster. A cluster with only two queue managers offers only marginal benefit over a network that is to use distributed queuing. It is a good way to start and it provides scope for future expansion. When you open new branches of our store, we are able to add the new queue managers to the cluster easily. Adding new queue managers does not disrupt the existing network; see Adding a queue manager to a cluster.

    For the time being, the only application we are running is the inventory application. The cluster name is INVENTORY.

  2. Decide which queue managers are to hold full repositories.

    In any cluster we must nominate at least one queue manager, or preferably two, to hold full repositories. In this example, there are only two queue managers, LONDON and NEWYORK, both of which hold full repositories.

    1. We can perform the remaining steps in any order.
    2. As you proceed through the steps, warning messages might be written the z/OS system console. The messages are a result of missing definitions that we have yet to add.
    3. Before proceeding with these steps, make sure that the queue managers are started.

  3. Alter the queue manager definitions to add repository definitions. On each queue manager that is to hold a full repository, alter the local queue manager definition, using the ALTER QMGR command and specifying the REPOS attribute: 
    ALTER QMGR REPOS(INVENTORY)

    1 : ALTER QMGR REPOS(INVENTORY)
AMQ8005: WebSphere MQ queue manager changed.
    For example, if you enter:
    1. runmqsc LONDON
    2. ALTER QMGR REPOS(INVENTORY)

    LONDON is changed to a full repository.

  4. Define the listeners.

    See The channel initiator on z/OS and Receive on LU 6.2.

    The listener is not started when it is defined, so it must be manually started the first time with the following MQSC command: 
    START LISTENER(LONDON_LS)
    Issue similar commands for all the other queue managers in the cluster, changing the listener name for each one.
  5. Define the CLUSRCVR channel for the LONDON queue manager.

    On every queue manager in a cluster, you define a cluster-receiver channel on which the queue manager can receive messages. See Cluster-receiver channel: CLUSRCVR . The CLUSRCVR channel defines the connection name of the queue manager. The connection name is stored in the repositories, where other queue managers can refer to it. The CLUSTER keyword shows the availability of the queue manager to receive messages from other queue managers in the cluster. 

    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(LU62)
CONNAME(LONDON.LUNAME) CLUSTER(INVENTORY)
MODENAME('#INTER') TPNAME('MQSERIES')
DESCR('LU62 Cluster-receiver channel for queue manager LONDON')

    1 : DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(LU62)
CONNAME(LONDON.LUNAME) CLUSTER(INVENTORY)
MODENAME('#INTER') TPNAME('MQSERIES')
DESCR('LU62 Cluster-receiver channel for queue manager LONDON')
AMQ8014: WebSphere MQ channel created.
07/09/98 12:56:35 No repositories for cluster 'INVENTORY'
  6. Define the CLUSRCVR channel for the NEWYORK queue manager. 
    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSRCVR) TRPTYPE(LU62)
CONNAME(NEWYORK.LUNAME) CLUSTER(INVENTORY)
MODENAME('#INTER') TPNAME('MQSERIES')
DESCR('LU62 Cluster-receiver channel for queue manager NEWYORK')
  7. Define the CLUSSDR channel on the LONDON queue manager.

    You manually define a CLUSSDR channel from every full repository queue manager to every other full repository queue manager in the cluster. See Cluster-sender channel: CLUSSDR . In this case, there are only two queue managers, both of which hold full repositories. They each need a manually-defined CLUSSDR channel that points to the CLUSRCVR channel defined at the other queue manager. The channel names given on the CLUSSDR definitions must match the channel names on the corresponding CLUSRCVR definitions. When a queue manager has definitions for both a cluster-receiver channel and a cluster-sender channel in the same cluster, the cluster-sender channel is started. 

    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(LU62)
CONNAME(CPIC) CLUSTER(INVENTORY)
DESCR('LU62 Cluster-sender channel from LONDON to repository at NEWYORK')

    1 : DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(LU62)
CONNAME(NEWYORK.LUNAME) CLUSTER(INVENTORY)
MODENAME('#INTER') TPNAME('MQSERIES')
DESCR('LU62 Cluster-sender channel from LONDON to repository at NEWYORK')
AMQ8014: WebSphere MQ channel created.
07/09/98 13:00:18  Channel program started.
  8. Define the CLUSSDR channel on the NEWYORK queue manager. 
    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSSDR) TRPTYPE(LU62)
CONNAME(LONDON.LUNAME) CLUSTER(INVENTORY)
DESCR('LU62 Cluster-sender channel from NEWYORK to repository at LONDON')
  9. Define the cluster queue INVENTQ Define the INVENTQ queue on the NEWYORK queue manager, specifying the CLUSTER keyword. 
    DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

    1 : DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)
AMQ8006: WebSphere MQ queue created.

    The CLUSTER keyword causes the queue to be advertised to the cluster. As soon as the queue is defined it becomes available to the other queue managers in the cluster. They can send messages to it without having to make a remote-queue definition for it.

    All the definitions are complete. On all platforms, start a listener program on each queue manager. The listener program waits for incoming network requests and starts the cluster-receiver channel when it is needed.


Verify the cluster

About this task

We can verify the cluster in one or more of these ways:
  1. Running administrative commands to display cluster and channel attributes.
  2. Run the sample programs to send and receive messages on a cluster queue.
  3. Write your own programs to send a request message to a cluster queue and reply with a response messages to an non-clustered reply queue.

Procedure

  1. Issue DISPLAY runmqsc commands to verify the cluster. The responses you see ought to be like the responses in the steps that follow.
    1. From the NEWYORK queue manager, run the DISPLAY CLUSQMGR command: 
      dis clusqmgr(*)

      1 : dis clusqmgr(*)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(NEWYORK)       CLUSTER(INVENTORY)
CHANNEL(INVENTORY.NEWYORK)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(LONDON)       CLUSTER(INVENTORY)
CHANNEL(INVENTORY.LONDON)
    2. From the NEWYORK queue manager, run the DISPLAY CHANNEL STATUS command: 
      dis chstatus(*)

      1 : dis chstatus(*)
AMQ8417: Display Channel Status details.
CHANNEL(INVENTORY.NEWYORK)  XMITQ( )
CONNAME(192.0.2.0)      CURRENT
CHLTYPE(CLUSRCVR)       STATUS(RUNNING)
RQMNAME(LONDON)
AMQ8417: Display Channel Status details.
CHANNEL(INVENTORY.LONDON) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) 
XMITQ(SYSTEM.CLUSTER.TRANSMIT.INVENTORY.LONDON)
CONNAME(192.0.2.1)      CURRENT
CHLTYPE(CLUSSDR)       STATUS(RUNNING)
RQMNAME(LONDON)

  2. Send messages between the two queue managers, using amqsput.
    1. On LONDON run the command amqsput INVENTQ LONDON.

      Type some messages, followed by a blank line.

    2. On NEWYORK run the command amqsget INVENTQ NEWYORK.

      You now see the messages you entered on LONDON. After 15 seconds the program ends.

  3. Send messages between the two queue managers using your own programs. In the following steps, LONDON puts a message to the INVENTQ at NEWYORK and receives a reply on its queue LONDON_reply.
    1. On LONDON put a messages to the cluster queue.
      1. Define a local queue called LONDON_reply
      2. Set the MQOPEN options to MQOO_OUTPUT
      3. Issue the MQOPEN call to open the queue INVENTQ
      4. Set the ReplyToQ name in the message descriptor to LONDON_reply
      5. Issue the MQPUT call to put the message
      6. Commit the message

    2. On NEWYORK receive the message on the cluster queue and put a reply to the reply queue.
      1. Set the MQOPEN options to MQOO_BROWSE
      2. Issue the MQOPEN call to open the queue INVENTQ
      3. Issue the MQGET call to get the message from INVENTQ
      4. Retrieve the ReplyToQ name from the message descriptor
      5. Put the ReplyToQ name in the ObjectName field of the object descriptor
      6. Set the MQOPEN options to MQOO_OUTPUT
      7. Issue the MQOPEN call to open LONDON_reply at queue manager LONDON
      8. Issue the MQPUT call to put the message to LONDON_reply

    3. On LONDON receive the reply.
      1. Set the MQOPEN options to MQOO_BROWSE
      2. Issue the MQOPEN call to open the queue LONDON_reply
      3. Issue the MQGET call to get the message from LONDON_reply