I found this chain very useful and I have one question, are there any performance implications in running an MQ Client remote to a QMGR on a mainframe as opposed to running a QMGR on a server local to the mainframe....just a high level question that is of interest......
Thank you very much
-----Original Message-----
From: MQSeries List [mailto:[email protected]] On Behalf Of Robert Broderick
Sent: 29 July 2005 17:13
To: [email protected]
Subject: Re: QM or MQ Client Argument
Take the suit off, too many bulls eyes and not enough amunition!!!! :-)
>From: "Wyatt, T Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[email protected]>
>To: [email protected]
>Subject: Re: QM or MQ Client Argument
>Date: Fri, 29 Jul 2005 09:21:42 -0400
>
>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]]On Behalf
>Of Michelle Russell
>Sent: Friday, July 29, 2005 2:40 AM
>To: [email protected]
>Subject: QM or MQ Client Argument
>
>
>Time and time again I get involved in new projects that want to utilise MQ.
>I have to work out the initial design of how the new project will use MQ.
>The dilemma we have is do we use an MQSeries Client or opt for a full blown
>Websphere MQ Manager. Can somebody point me in the direction of any
>material that will give me an overview of the 'for's' and 'against' for
>each.
>Regards
>Michelle
>
>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
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
