Costa, D. (Damian)
2014-01-21 09:58:47 UTC
Hi all,
We're discussing the possibilities of limiting the qmgr growth in our MQ networks. Every new project pops up all wanting their own qmgrs on their own servers. Its creating a maintenance and support nightmare for our small team. It's taking us a year to deploy a new version of MQ across the environment.
What we'd like to do is propose having a limited number of HUB qmgr servers that service multiple applications using MQ client connections.
It does then bring in the question of who manages all the MQ client installs and support.
What we're trying to avoid is deploying MQ clusters as there are security concerns with locking down a cluster.
We already have a queue sharing group of qmgrs on MVS servers which works very well. we're going to retain that infrastructure.
If we replace the direct bindings for all the apps with an MQ client we are looking at losing a bit of assured delivery but gain on the turnaround times and delivery for projects.
What do you all think about the key selling point of MQ being the assured delivery capability is it an endangered species or still a focus point for MQ in the future. I ask because the V7.0 changes where performance was the priority over the robustness of an MQ connection. And all the improvements to the MQ client connection experience: i.e. automatic reconnects, controlling individual client connections resource usage etc etc.
We'd probably need to look at making the apps more robust i.e. capable of surviving a lost message and adding a form of recon protocol that would catch the lost messages scenario. At least the app developers would.
So, How do your MQ networks handle new projects and their use of MQ as a transport layer? I.e. do you add qmgrs to your networks or just let them connect to a qmgr cluster or other topology?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
We're discussing the possibilities of limiting the qmgr growth in our MQ networks. Every new project pops up all wanting their own qmgrs on their own servers. Its creating a maintenance and support nightmare for our small team. It's taking us a year to deploy a new version of MQ across the environment.
What we'd like to do is propose having a limited number of HUB qmgr servers that service multiple applications using MQ client connections.
It does then bring in the question of who manages all the MQ client installs and support.
What we're trying to avoid is deploying MQ clusters as there are security concerns with locking down a cluster.
We already have a queue sharing group of qmgrs on MVS servers which works very well. we're going to retain that infrastructure.
If we replace the direct bindings for all the apps with an MQ client we are looking at losing a bit of assured delivery but gain on the turnaround times and delivery for projects.
What do you all think about the key selling point of MQ being the assured delivery capability is it an endangered species or still a focus point for MQ in the future. I ask because the V7.0 changes where performance was the priority over the robustness of an MQ connection. And all the improvements to the MQ client connection experience: i.e. automatic reconnects, controlling individual client connections resource usage etc etc.
We'd probably need to look at making the apps more robust i.e. capable of surviving a lost message and adding a form of recon protocol that would catch the lost messages scenario. At least the app developers would.
So, How do your MQ networks handle new projects and their use of MQ as a transport layer? I.e. do you add qmgrs to your networks or just let them connect to a qmgr cluster or other topology?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES