| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CommitMode/Response Mode impact |
« View previous topic :: View next topic » |
| Author |
Message
|
| DryHeatDave |
 Posted: Fri Apr 21, 2006 6:34 am Post subject: CommitMode/Response Mode impact |
 |
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
THis is a little strange.
I am building SOA services exposed via .NET web services. Request messages go via OTMA into IMS.
I don't have much OTMA experience. But I am told (by client people, who've done this before), that when a Request message hits the bridge queue, with an IIH with CommitMode set to 1 Send-then-commit, OTMA will create the IMS message from the MQ request & pass it through & then wait for the reponse to be passed back through OTMA. But if we set CommitMode to 0 Commit-then-send, OTMA will not wait for the response (we MQPUT Responses to a remote queue, local to the web service & currently get DFS2082 errors).
Q. What changes, based on CommitMOde value ? I guess the scope of at least one unit of work will change. Why does OTMA wait for a Reponse from COmmitMode 1, but not 0?
I'm guessing we might change the message type in the MD from Request to Datagram (and change response also to datagram). But I think in the context of MQ & the overall service architecture that Request/response is still valid.
Unfortunately, we have to allow for the services to also be consumed in IMS, via an LTERM, so we can't change the transaction definition to NORESPONSE - we have to be able to lock an LTERM to wait for the response.
This is really an issue of a mature (old) client not wanting to change IIH default value of CommitMode. But I think I will still try to convince them to change once I understand exactly what's happening.
THX.
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Apr 21, 2006 6:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are you getting back valuable business data from the IMS transaction?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| DryHeatDave |
| Posted: Fri Apr 21, 2006 7:06 am Post subject: |
|
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
Yes - via the MQPUT. Some services are updates & we only send back confirmations. But there are Inquiries too, sending back transaction history - which (due to volume) was the reason we don't just send back Responses via OTMA.
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Fri Apr 21, 2006 10:14 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
//
From manual:
WebSphere MQ message type Commit-then-send (mode 0) - uses synchronized IMS Tpipes
Send-then-commit (mode 1) - uses non-synchronized IMS Tpipes
Reply messages from IMS
When an IMS transaction ISRTs to its IOPCB, the message is routed back to the originating LTERM or TPIPE. These are seen in WebSphere MQ as reply messages. Reply messages from IMS are put onto the reply-to queue specified in the original message. If the message cannot be put onto the reply-to queue, it is put onto the dead-letter queue using the authority of the bridge. If the message cannot be put onto the dead-letter queue, a negative acknowledgement is sent to IMS to say that the message cannot be received. Responsibility for the message is then returned to IMS. If you are using commit mode 0, messages from that Tpipe are not sent to the bridge, and remain on the IMS queue; that is, no further messages are sent until restart. If you are using commit mode 1, other work can continue.
Using alternate response PCBs in IMS transactions
When an IMS transaction uses alternate response PCBs (ISRTs to the ALTPCB, or issues a CHNG call to a modifiable PCB), the Pre-routing Exit (DFSYPRX0) is invoked to determine if the message should be rerouted. If the message is to be rerouted, the Destination Resolution Exit (DFSYDRU0) is invoked to confirm the destination and prepare the header information See WebSphere MQ for z/OS System Setup Guide for information about these exit programs.
Unless action is taken in the exits, all output from IMS transactions initiated from a WebSphere MQ queue manager, whether to the IOPCB or to an ALTPCB, will be returned to the same queue manager.
Sending unsolicited messages from IMS
To send messages from IMS to a WebSphere MQ queue, you need to invoke an IMS transaction that ISRTs to an ALTPCB. You need to write pre-routing and destination resolution exits to route unsolicited messages from IMS and build the OTMA user data, so that the MQMD of the message can be built correctly. See the WebSphere MQ for z/OS System Setup Guide for information about these exit programs.
Note:
The WebSphere MQ-IMS bridge does not know whether a message it receives is a reply or an unsolicited message. It handles the message the same way in each case, building the MQMD and MQIIH of the reply based on the OTMA UserData that arrived with the message
Unsolicited messages can create new Tpipes. For example if an existing IMS transaction switched to a new LTERM (for example PRINT01) but the implementation required that the output be delivered through OTMA; a new Tpipe (called PRINT01 in this example) would be created. By default this will be a non-synchronized Tpipe. If the implementation requires the message to be recoverable the destination resolution exit Output flag must be set. See the IMS Customization Guide for more information.
//
It sounds (if i'm not wrong) that you need the PRX & DRU exits on IMS.
We have not any problems with Commit 0/1 , except the overhead on IMS WADS with the Commit 0 IIH tx.
To Know more from OTMA:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.ims9.doc.otma/otma.htm
Regards |
|
| Back to top |
|
|
| DryHeatDave |
| Posted: Fri Apr 21, 2006 12:58 pm Post subject: |
|
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
I've printed your response & I'll think about it over the weekend 
THX.
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
