This section describes the simplest way to send a message from one queue manager to another.
Before you do this you need to do the following:
You also need to have the correct WebSphere MQ security authorization to create the objects required.
To send messages from one queue manager to another:
You can use several different methods to define these objects, depending on your WebSphere MQ platform:
The different methods are described in more detail in the platform-specific parts of this book.
To send messages from one queue manager to another, you need to define two channels; one on the source queue manager and one on the target queue manager.
Details of all the channel attributes are given in Chapter 6, Channel attributes.
Specify the name of the communication protocol you are using (the TRPTYPE attribute). For WebSphere MQ for AIX, iSeries, HP-UX, Solaris and Windows systems, and MQSeries for Compaq Tru64 UNIX, and OS/2 Warp, you do not have to specify this. You can leave it to pick up the value from your default channel definition. If you are using CICS to define a channel, you cannot specify TRPTYPE. Instead you should accept the defaults provided. On MQSeries for VSE/ESA, you can choose T (TCP) or L (LU 6.2) on the Maintain Channel Definition menu. On WebSphere MQ for z/OS, the protocol must be TCP or LU6.2.
Note that receiver channel definitions can be generic. This means that if you have several queue managers communicating with the same receiver, the sending channels can all specify the same name for the receiver, and one receiver definition will apply to them all.
When you have defined the channel, you can test it using the PING CHANNEL command. This command sends a special message from the sender channel to the receiver channel and checks that it is returned.
To send messages from one queue manager to another, you need to define up to six queues; four on the source queue manager and two on the target queue manager.
In this definition you specify the following:
Required on z/OS, and optional on other platforms. On z/OS you must use the initiation queue called SYSTEM.CHANNEL.INITQ and you are recommended to do so on other platforms also.
A local queue with the USAGE attribute set to XMITQ. If you are using the WebSphere MQ for iSeries native interface, the USAGE attribute is *TMQ.
Define a dead-letter queue to which undelivered messages can be written.
The target queue. The name of this queue must be the same as that specified in the remote queue name field of the remote queue definition on the source queue manager.
Define a dead-letter queue to which undelivered messages can be written.
When you put messages on the remote queue defined at the source queue manager, they are stored on the transmission queue until the channel is started. When the channel has been started, the messages are delivered to the target queue on the remote queue manager.
Start the channel on the sending queue manager using the START CHANNEL command. When you start the sending channel, the receiving channel is started automatically (by the listener) and the messages are sent to the target queue. Both ends of the message channel must be running for messages to be transferred.
Because the two ends of the channel are on different queue managers, they could have been defined with different attributes. To resolve any differences, there is an initial data negotiation between the two ends when the channel starts. In general, the two ends of the channel agree to operate with the attributes needing the fewer resources, thus enabling larger systems to accommodate the lesser resources of smaller systems at the other end of the message channel.
The sending MCA splits large messages before sending them across the channel. They are reassembled at the remote queue manager. This is transparent to the user.
An MCA can transfer messages using multiple threads. This process, called pipelining enables the MCA to transfer messages more efficiently, with fewer wait states. This improves channel performance.