Philip -- Would you be able to go into a bit more detail on the following point in terms of how you do this:
Administering SVRCONN channels can be localized by creating unique listener processes for each application (or sub-application). Naming standards also help here as well. Thanks, Barbara -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 29, 2005 10:52 AM To: [email protected] Subject: Re: QM or MQ Client Argument All, Purchasing, Administering, monitoring, and configuring a queue manager is far more expensive then using MQClient. If DB update coordination is not needed, then using MQClient should be considered. Our TCO analysis clearly shows a substantial benefit in reducing MQServer instances. This is especially true for applications that have relatively low volume. Grouping such apps together to share a queue manager through MQClient has a great many advantages. Reduction in MQAdministration and administrators. Reduction in software licences. Reduction in MQ savvy specialists. Creation and adherence to firm wide standards (naming, design patterns, security, ...) Focused monitoring, paging, alerting, accounting, charge-back... When creating generalized the MQ Computing environment we've been able to provide far better Failover and DR services that meet or exceed SLA requirements. Yes we use SSL, Yes we use a security exit. Yes we collect statistics for performance and usage based charge-back. Yes we enforce standards. Administering SVRCONN channels can be localized by creating unique listener processes for each application (or sub-application). Naming standards also help here as well. Applications are encouraged to utilize "exception" queues for error handling.... lots more on this. The point is defining a clear "onboarding" process that includes design reviews if needed. In line with IBM's Service Integration Bus just my two cents... Philip Scott Meridew <[EMAIL PROTECTED]> To: [email protected] Sent by: MQSeries List cc: <[EMAIL PROTECTED] Subject: Re: QM or MQ Client Argument wien.ac.at> 07/29/2005 09:52 AM Please respond to MQSeries List I completely agree with T.Rob on this one. Clients are free...and you get what you pay for. I like removing the mystery that is the network from my concerns...and clients, although flexible and cheap, simply further my headaches. Scott Meridew Director of Professional Services TxMQ Inc. Office 716-564-1700 x27 Mobile 416-846-9939 Home Office 905-693-8535 -----Original Message----- From: Wyatt, T Rob Date: 29/7/05 8:22 am To: [email protected] Subj: Re: QM or MQ Client Argument Hi Michelle, We may be a bit conservative in that we prefer full QMgrs with local bindings here for several reasons as follows: With local bindings you get trusted authentication at the OS and authorization with the OAM. With SVRCONN channels you cannot trust the authentication unless you use SSL and take precautions to secure the certificate stores on the client hosts. In addition, SVRCONN channels do not provide authorization unless you use an MCAUSER value or an exit such as BlockIP2 which will filter out privileged IDs like mqm or blanks. By default a SVRCONN channel opens up full admin privileges to the whole world. With a SVRCONN channel the MCA puts the full MQ API under control of the remote program which may or may not be well-behaved. With server-to-server channels the MCA is IBM's code. In the most mild case you can get clients who do not use FAIL_IF_QUIESCING and prevent a clean shutdown of your QMgr. In the worst case you can get clients who bring your QMgr to it's knees. We had a vendor-written client with a reconnect loop that had no sleep. Everything was fine for a while then one day it hiccupped and get into the reconnect loop. Tried to reconnect about 1000 times per second. Filled the listener backlog, prevented all attempts to connect to the QMgr by other channels (including our administrative tools) failed. Since we were using inetd, we could not keep the amqcrsta processes down long enough to restart the QMgr. Nowadays if we let clients connect at all, it is to a client concentrator QMgr and not our major application QMgrs. When using clients if you get a 2009 Connection Broken response you do not know if the connection was broken before or after it reached the agent at the QMgr. If you did a GET or PUT outside of syncpoint and get a 2009 you may - or may not - have completed the call on the QMgr. So let's assume you are doing everything under syncpoint and get a 2009 on the COMMIT. If you had removed messages from the queue and the COMMIT never made it to the agent, you will get them back again. Hopefully you coded to recognize them as dupes. In the case of a PUT, you really do not know if the PUT was successful. You can get around this with code by placing a message into a sync queue outside of syncpoint. Then you GET the same message under syncpoint and do any other GETs or PUTs for your transaction. If you get a 2009 on the COMMIT you can check the sync queue to see if the token message is there or not. Of course it may sit under syncpoint for several minutes before being rolled back when the channel agent times out. In general, we have found that having a full QMgr is less costly than making the client robust enough for our application requirements. I believe this is in fact the basis for IBM charging as much for the transactional client as a full QMgr. The exceptions in our shop are things like inquiry transactions or applications which have the capability to resynch themselves automatically and do not store state in the messages. Hope that helps, -- T.Rob (I'm donning my asbestos suit in anticipation of a firestorm now!) -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Michelle Russell Sent: Friday, July 29, 2005 2:40 AM To: [email protected] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
