| Author |
Message
|
| atheek |
 Posted: Sun Nov 09, 2008 2:47 pm Post subject: |
 |
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| Also does the IMS bridge improve the performance and throughput? We have a real time request reply web applicationt that back ends with an IMS transaction. The mainframe team has provided two versions of the transaction - one using normal MQ and other uses IMS bridge. I have been advised by the mainframe team to use the IMS Bridge version for real time request reply with a user waiting for the reply as the response times were said to much better than the MQ version. Is this true? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Nov 09, 2008 3:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| atheek wrote: |
| Also does the IMS bridge improve the performance and throughput? We have a real time request reply web applicationt that back ends with an IMS transaction. The mainframe team has provided two versions of the transaction - one using normal MQ and other uses IMS bridge. I have been advised by the mainframe team to use the IMS Bridge version for real time request reply with a user waiting for the reply as the response times were said to much better than the MQ version. Is this true? |
Make a poc and check it both ways. What is true for others might not be true for you... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| atheek |
| Posted: Sun Nov 09, 2008 9:28 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
Thanks FJ..( also for moving it to a new thread  )
We have this app in production...during the design phase of that project it was told to us by the mainframe guys that IMS bridge is more suited for real time request reply. So was wondering whether this a valid point to be considered when discussing the MQ components required for Z/OS |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 10, 2008 6:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you do not use the bridge (real hi level):
MQ message hits the MQ queue
QM creates trigger message to Init Q
Trigger Monitor consumes the trigger message
Trigger Monitor starts the TCODE by placing a message in the IMS queue
IMS app starts up
IMS app does an MQGET off of the MQ queue
If you use the bridge:
MQ message hits the MQ queue
IMS bridge picks up the MQ message, processes it and inserts it to the IMS queue
The IMS app start and process the data.
At a real high level, there are fewer steps with the bridge, so you might guess that it will be faster. How you have both set up determines how fast each is. Like FJ said, you will have to test to see the real results.
And don't forget, something that takes 0.0001 seconds is twice as fast as something that takes 0.0002 seconds, but does it matter unless you are doing thousands a second?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| atheek |
| Posted: Mon Nov 10, 2008 1:17 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
Thanks Peter. The mainframe guys are quite experienced and advised us, so they would have set up a better IMSBridge transaction rather than the MQ one
IMSBridge is in fact performing really well for real time request reply. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 10, 2008 2:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Performs well here too. Just some extra non MQ parts to consider when problem resultion time comes. If you got good IMS guys, this is not an issue. It can be more complicated for the front end guys to get the format of the MQ message just right so the IMS bridge can pass it successfully to IMS.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
