Consider two queue managers, QM_A and QM_B. There is a local queue on QM_B called Queue_One. Initially, this is only accessible to QM_B. To get access to Queue_One, QM_A needs a remote queue definition, usually abbreviated to remote queue. When referring to the remote queue definition, use the term queue queue manager to refer to QM_B, that is, the queue queue manager is the queue manager upon which the local queue referenced by the remote queue definition resides.
In summary, remote queues are references to queues that reside on a queue manager that itself is remote to where the remote queue is defined. The remote queue has the same name as the target queue but the remote queue definition identifies the owning or target queue manager of the real queue.
The remote definition of the queue should, in most cases, match that of the real queue. If this is not the case, different results may be seen when interacting with the queue. For example, for asynchronous queues, if the maximum message size on the remote definition is greater than that on the real queue, the message is accepted for storage on the remote queue, but may be rejected when moved to the real queue. The message is not lost, it remains on the remote queue, but it cannot be delivered.
If the security characteristics for a synchronous queue do not match, WebSphere MQ Everyplace negotiates with the real queue to decide what security characteristics should be used. In some cases, the message put is successful, in others an attribute mismatch exception is returned.