Jeff,
using CICS as the backend application server, A combination of MQRO_COD,
MQRO_EXPIRATION, and Expiry options on the Puts, (Request, and Reply),
you can build your own Synchonous Business transaction. The first 3
options will tell you if the messages made it to the application code on
the other side.
>From the requester view.
1. COD (confirm on delivery) the message made it to the remote
applicaton
2. Expiration the message expired before the remote
application was able to process the message
3. No response Either the sender or receiver channel
is down. Back out the message. because the server
application will not be able to get a response on the reply and will
backout the message
>From the server view:
1. COD the reply was delivered to the requester, go
ahead and complete
2. Expiration the reply message was not delivered to the
requester. Back out the request.
3. No response here you have an indoubt situation. Write to
an error log, roll-back commit based on you own
requirements. Though you could add one more
message from the requester to server to complete
application sync level 2 processing.
There is still a small indoubt window, but that is there no matter what
protocal you are using.
Glen Larson
Zurich North America
Jeff A Tressler <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 01/10/2003 03:04:05
PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Using MQSeries for ALL Synchronous Traffic
Someone has had a wonderful idea. Since MQSeries is fast and reliable, it
should be used for all data traffic. This includes all data transfer that
is
synchronous in nature.
For example, creation of a web front end for out legacy mainframe
applications.
The user enters the data on a web page, the data is formatted into a
message,
sent to the mainframe via MQSeries, the messages is processed and a reply
is sent back through MQSeries, a results web page is created and sent to
the
user.
We have this design implemented in a limited manor and it works. The
design is not bad since it is only being used by a couple dozen people
and the messages sent to the mainframe are actually fire-and-forget
transactions. The reply is along the lines of "message received." If
the message does not get back in 15 seconds we send a "check the
status later" screen.
Now the powers that be want to use this type of asynchronous facility for
all communications. Even if the user MUST get a valid reply on the status
of the request and MUST get this in a timely manner.
Does anyone know of any white papers that may discuss the problems of
using an asynchronous transport mechanism to solve a synchronous task. We
are looking for technical as will as business reason to strengthen our
argument against this direction.
Jeff Tressler
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
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents. Thank you.
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
