Allow MQGet/MQPut nodes to be looped in for a given set of QueueManagers/queues at runtime

Idea / RFE Review. Thank you for taking the time to raise this suggestion, and also for the interaction which has taken place through the service case which was raised on the same topic. Unfortunately on this occasion we do not intend to take this suggestion further forward. The main reason for this is a concern over the way in which you are viewing the dynamic addition of new queue managers in your network. If the intended use case here could accurately be described as "a new Queue Manager has been brought into operation and now I want ACE to read from it", then we would expect either a new flow to be deployed with an MQInput node configured appropriately to take messages from the new queue manager, or an existing flow could be extended with a policy that links to the new queue manager / or new branch of flow logic that deals with the new message feed. This kind of design reflects the fact that MQ is not really designed to have applications connect to it based on a file being updated with connection details ... some research on MQ trigger monitors may be helpful here as an alternative design. This commentary is based around the queue manager aspect of the use case .. where queues on an existing queue manager are concerned, you can use existing flow facilities for iterating over different queues using the MQGet node in combination with settings in the LocalEnvironment to specify the queue name dynamically. A final point worthy of note is that if you are adamant that you need queue manager dynamic connections (not using MQ options such as trigger monitor or uniform clustering, which would also be worth some research) then this could be achieved with bespoke java logic in a JavaCompute node, but as previously mentioned we would not encourage this workaround as we really feel a more basic appraisal of the interactions with MQ would be better.