Oh. Now that I look at the old step, I don't think you *can* subscribe to a remote queue using Override Queue Manager ("Alt QManager" in the old step). You can only subscribe to a queue that is local to the Queue Manager you're actually connecting to. For publishing, anything goes. But for subscribing, the queue has to be local.
This means that, in order to listen on those five queues, you will actually have to connect directly to those five queue managers. This is *possible*, but pretty difficult to do with the old IBM MQ Native protocol. You have to significantly customize the VSM to add multiple Listen steps. Such a custom configuration is not something we've documented well or rigorously tested, especially with something that's been deprecated for two years. I strongly recommend upgrading to the latest GA instead if you have to go this route.
By this point you should probably be asking why you have to use a clustered request queue for a virtual service. You're demultiplexing requests to multiple queues and then turning around and re-multiplexing them back to a single virtual service. This is a lot of complexity for no benefit that I can see.
If the problem is that messages can be published to any of those five queue, then a much simpler setup with remote queues pointing to a single request queue on a single Queue Manager can solve that.
If the problem is that you have no control over the source of the requests, or the queue architecture, or the version of DevTest you can use, then we can still try and help you. But it's not going to be easy.
The first thing you should do is to see if you can actually subscribe directly to one of the five request queues. If there are any access, firewall, or permissions issues there then those will need to be worked out before you can proceed.
After that, you will probably need to contact support for some more direct attention. I don't remember exactly how the trick with multiple Listen steps worked, so we may have to iterate with you on that.