T.Rob,
This is good advice and I agree whole heartedly that the application
programmer must deal with 2009 reason codes correctly and perform message
operations in syncpoint if you need to ensure 100% reliability. However, I
do not agree that this is a client thing. Exactly the same decisions must
be taken in the server application. There is no difference between the
transactional programming model on the client and on the server. (except
perhaps XA transactions and let's not start that debate). The only
difference in the client is that the windows and opportunities for getting
a 2009 are somewhat larger because you have a TCP socket in the way.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|---------+------------------------------->
| | "Wyatt, T. Rob" |
| | <[EMAIL PROTECTED]|
| | MERICA.COM> |
| | Sent by: MQSeries |
| | List |
| | <[EMAIL PROTECTED]|
| | C.AT> |
| | |
| | |
| | 30/09/2003 16:27 |
| | Please respond to |
| | MQSeries List |
| | |
|---------+------------------------------->
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: A program the uses MQSeries Client and Server libraries
|
|
|
|
|
>--------------------------------------------------------------------------------------------------------------|
Jeff,
Sorry, not going to answer your question but have some related advice.
Yes,
it is true that you can write code that runs the same on client and server
bindings. Just be sure to write the code to the more rigorous standards
required for a client.
Specifically, you want to do everything under syncpoint and figure out how
to handle the 2009 return code. A 2009 means that your connection to the
QMgr was lost. The problem is that you do not know whether it was lost
BEFORE the MCA got your request or AFTER. So, for example, if you get a
2009 on a PUT, the call may have worked, or it may not. If you are making
your calls under syncpoint you can be assured the PUT will be rolled back
if
you get a 2009.
Under syncpoint, the only exposure is if you get a 2009 on a COMMIT. In
this case, your messages MAY have been committed or MAY NOT. When your
program reconnects, it has no way of knowing so you have to decide - do I
redo any PUT and GET activity or not? If the application tolerates dupes
well, you can just restart the previous transaction and repeat any PUT or
GET activity.
We found a bug under MQ 5.3 where the listener threw 2009 on a GET with
convert but inetd handled it fine. This problem went away when we moved to
the latest client.
-- T.Rob
-----Original Message-----
From: Jeff A Tressler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 11:03 AM
To: [EMAIL PROTECTED]
Subject: A program the uses MQSeries Client and Server libraries
We are writing a program that will be able to access either the MQSeries
client
or MQSeries server depending on the system it runs on.
My understanding is that the code can be written such that no changes are
needed
and the method of connection (Client or Server) depends upon which set of
MQSeries
libraries the program links with. This would create two different
executable, one for
a MQSeries Client system and another for a MQSeries Server system
Is there a way to create a single executable which will recognize it is on
a MQSeries
server and perform accordingly and if not, perform as if it were running on
a MQSeries
client system?
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
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
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
