Hi Glen, I know I won't really be answering your concrete questions below, but from what you describe I get the feeling that your requirements might be better addressed by thinking about clustering your Windows servers, not necessarily your queue managers. MQ clustering doesn't really give you high availability, especially not if you have inherent request-reply affinities. Clustering the Windows boxes will give you HA functions, plus it has the least impact on your application design, since the only thing you have to do is to implement some sort of re-connection logic for your clients to respond to a 2009 (connection broken) reason code during a cluster node takeover event. I believe there is a support pack to talk about MQ support for MS Cluster Services pre MQV5.3 and I also believe that that support is shipped with V5.3. Sorry for navigating around your real questions, but I hope this is helpful, too. Cheers, Stefan
From: Glen Larson <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: A couple of clustering questions Date: Tue, 25 Mar 2003 11:19:18 -0600
We are starting to look at clusters in order to provide some close to 24x365, on our W2K nodes.
These Queue Managers (5.3) on W2K service other NT/W2K servers with MQClient installed (5.2, csd04). The MQServers, have an application to service the requests, and that also request info from Legacy applications on MVS (CICS, Batch & DB2 via MQ.
1) On the front end side the programs are written in ActiveX. They put requests on the queue, and come back later to look for a response. Not a problem now since only one queue manager to connect to. With Clustering they need to insure they go back to the correct queue manager to retrieve their data. What field is available to the ActiveX application, that has the true name of the Queue manager. So far the ones that they have tried, have given the generic cluster qmgr name. If this was the standard API, they would be told to use the info in the object descriptor after the connection, or the MSG header after the put.
2) On the MVS back-end, similar problem when to send the reply. For CICS not a problem, using PUT1. For long running batch where requests will come from multiple requesters, PUT1 would incur to much overhead. So, we wish to use the MQOO_BIND_NOT_FIXED option, and route the reply based on the name in the REPLY-TO-QMGR field for each reply message. We have search the doc, and have not found an example of how this is specified on the PUT. We attempted to use the MQOD_OBJECTQMGRNAME, but that did not work.
thanks Glen Larson Zurich North America
******************* PLEASE NOTE ******************* This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
