We used to use a "concentrator" - basically an MQ server instance on a
windows server - for client connections to the mainframe.
As you say I think this was a leftover from the early days. When we last
came to need to upgrade the MQ on the windows box (to stay on a
supported release), we removed this and connected our clients directly
to the m/f. For us the cost of the client attachment feature for z/OS
was offset by the saving on having to buy the new MQ release on windows
and longer term we actually saved money when you took into consideration
the maintenance on the servers, other mandatory s/w on the servers, MQ
monitor agents or the like on the server and disaster recovery
arrangements for the server etc. It is easy to overlook these areas
because it is "just a concentrator" but if it goes it doesn't really
matter how robust you m/f is as far as those client connections go -
this was another benefit for us.
I think for most m/f shops the cost of the CAF is small beer compared to
the cost of your m/f MQ server licenses and other IBM m/f s/w costs and
would probably get sunk in your enterprise wide license agreement,
assuming you have one. I don't know why IBM continues to insist on
charging separately for it when they don't on any other platform.
However as an organization we have pretty tight restrictions on when and
where MQ client solutions can be used and for us this is often the
driver to a server-server configuration instead of a client one for many
applications.
Pete
-----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]
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
Notice to recipient:
The information in this internet e-mail and any attachments is confidential and
may be privileged. It is intended solely for the addressee. If you are not the
intended addressee please notify the sender immediately by telephone. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may be
unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America, N.A.,
London Branch, Banc of America Securities Limited and Banc of America Futures
Incorporated are authorised and regulated by the Financial Services Authority.
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
