Bobbee...Appreciate the comments.....Thank you
-----Original Message-----
From: MQSeries List [mailto:[email protected]] On Behalf Of Robert Broderick
Sent: 02 August 2005 13:41
To: [email protected]
Subject: Re: QM or MQ Client Argument
It has been stated that an MQ server to server connection has a higher
throughput for messaging than a client based connection. I would suspect if
you pop around in the support pack area there might be numbers published by
IBM.
Just as a note. And this is from several client engagements. Most MF systems
tend to frown on Client connections. They usually prefer a "concentrator"
box upfront to act as a passthru/proxy to zOS.
This might be a leftover from early days where client connection could run
amuk and there was no way to control them. Which has changed now. OR MF
System Admins just didn't feel comfortable with client access from MQ (new
boy on the block). Either way, and maybe some reasons I don't know about,
that may be an uphill battle for you. Not to mention that the Client
Attachment Facility is a seperatly purchased piece for the MF. I would
suspect that considering the cost of a Windows/UNIX server with MQ on it,
the cost to go with the server on that platform for server to server
connection may be cheaper than the Client Attachment Facility on the beast
bobbee
>From: "Herd, Stewart" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[email protected]>
>To: [email protected]
>Subject: Re: QM or MQ Client Argument
>Date: Tue, 2 Aug 2005 04:01:59 -0500
>
>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
>
>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
