Add QREMOTE and XMITQ functionality to the Streaming Queues feature

In my view, it is a critical feature. The example provided is a very common MQ use case. An application sends a messages to a queue which flows over a channel to a remote queue manager. When placed on the local queue, it can be streamed. An application processes and then sends a reply. The reply goes to a remote queue but there is no way to stream this reply. Remote and transmission queues are excluded from streaming. One option would be using a remote queue definition similar to way a remote queue manager definition is used to define remote queues that could be streamed would close this gap.

A natural extension to the use cases for streaming queues is to allow more than one destination queue, ie. define a name list of queues as an alternative to just one queue.

If this feature were available, we could replace our current message duplication solution using pub sub (QALIAS targtype=topic -> TOPIC -> One or more SUB objects -> Destination queues), with a native feature of MQ. We have cases of 2, 3 and 4 destination systems that need to receive a copy of the same message.

This is the only STREAMING Queue requirement left, except from the original Message duplication improvement request, given the existence of the STREAMING feature for quite some time now and given the need for 'outbound' messages to be captured from source rather then at the destination adding STREAMING queue feature to at least QREMOTE would be a valid request and should be taken into consideration at some point!

QREMOTE only support for Streaming Queues would help greatly,

XMITQ would probably be too much and involve more security scrutiny.

We can see potential value in this idea, but it is not likely at the moment to be prioritised against other items. As a result we are declining this. While declined the Idea can still be voted, and commented, upon. We are likely to wait until there is a bit more experience with the current capabilities before revisiting the area.