MQ objects required to use parallel send queues

When you use multiple (parallel) send queues to deliver messages, you also need to create multiple transmission queues and channels – one transmission queue, sender channel, and receiver channel for each send queue.

Figure 1 shows the IBM® MQ objects that are required to use parallel send queues.

Figure 1. MQ objects that are required for parallel send queues. Six channel objects are required to create a transmission path between the source and target systems for the three send queues, each with its own transmission queue. Two channel objects are also required to create a transmission path from the target system to the source system for control messages from the Q Apply program.
Diagram of MQ objects that are required to use parallel send queues

The following lists show the objects that are required to use parallel send queues for unidirectional replication between two remote servers:

Non-channel objects on source system
  • A queue manager
  • Two to four remote queue definitions to serve as the parallel send queues (these queues point to a single receive queue on the target system). The send queues must be defined in the following format:
    send_queue_name.suffix

    Where send_queue_name remains the same for all send queues that are part of the replication queue map, and suffix is an integer between 1 and 4. For example, if you want to use three parallel send queues, you would define the send queues by using a naming scheme that is similar to the following example:

    ASN.SRC_TO_ASN.TGT.DATA.1
ASN.SRC_TO_ASN.TGT.DATA.2
ASN.SRC_TO_ASN.TGT.DATA.3
  • A local queue to serve as the administration queue
  • A local queue to serve as the restart queue

Non-channel objects on target system
  • A queue manager
  • A local queue to serve as the receive queue
  • A remote queue definition to serve as the administration queue (this queue points to an administration queue on the source system)
  • A model queue definition for any temporary local spill queues that the Q Apply program creates and uses while it loads target tables
    Note: If you have multiple Q Apply programs that share the same queue manager, each Q Apply program must have its own model queue with a name that is unique under that queue manager.
Channel from source to target
  • For each send queue, a sender channel that is defined within the source queue manager
  • For each send queue, an associated local transmission queue
  • For each send queue, a matching receiver channel that is defined within the target queue manager

Channel from target to source
  • A sender channel that is defined within the target queue manager
  • An associated local transmission queue
  • A matching receiver channel that is defined within the source queue manager

The following example shows the MQ commands and a naming scheme to create three parallel send queues between the SRC and TGT databases:
* Send queues for Q Capture on SRC
DEFINE QREMOTE('ASN.SRC_TO_ASN.TGT.DATA.1') RNAME('ASN.SRC_TO_ASN.TGT.DATA')
  RQMNAME('QMSRC') XMITQ('QMTGT.1')
DEFINE QREMOTE('ASN.SRC_TO_ASN.TGT.DATA.2') RNAME('ASN.SRC_TO_ASN.TGT.DATA')
  RQMNAME('QMSRC') XMITQ('QMTGT.2')
DEFINE QREMOTE('ASN.SRC_TO_ASN.TGT.DATA.3') RNAME('ASN.SRC_TO_ASN.TGT.DATA')
  RQMNAME('QMSRC') XMITQ('QMTGT.3')

* Transmission queue for Q Capture
DEFINE QLOCAL('QMTGT.1') USAGE(XMITQ)
DEFINE QLOCAL('QMTGT.2') USAGE(XMITQ)
DEFINE QLOCAL('QMTGT.3') USAGE(XMITQ)

* Sender channels
DEFINE CHL ('QMSRC_TO_QMTGT.1') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘host.tgt(5556)')
  XMITQ('QMTGT.1')
DEFINE CHL ('QMSRC_TO_QMTGT.2') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘host.tgt(5556)')
  XMITQ('QMTGT.2')
DEFINE CHL ('QMSRC_TO_QMTGT.3') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘host.tgt(5556)')
  XMITQ('QMTGT.3')

* Receive queue for Q Apply on TGT
DEFINE QLOCAL('ASN.SRC_TO_ASN.TGT.DATA')

* Receiver channels
DEFINE CHL ('QMSRC_TO_QMTGT.1') CHLTYPE(RCVR) TRPTYPE(TCP)
DEFINE CHL ('QMSRC_TO_QMTGT.2') CHLTYPE(RCVR) TRPTYPE(TCP)
DEFINE CHL ('QMSRC_TO_QMTGT.3') CHLTYPE(RCVR) TRPTYPE(TCP)