| Author |
Message
|
| wmqiguy |
 Posted: Mon Nov 25, 2002 8:02 am Post subject: CICS Bridge -- MQMD |
 |
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Scenario (trust me on this  ):
Request message goes to QMGR A (NT), then QMGR B (WMQI), then to QMGR C (CICS Bridge). The trick is getting the reply back to QMGR A (through WMQI).
My concern is with the behavior of the Bridge. I want to have WMQI hide the originating QMGR (QMGR A) in the MQMD or MQCIH and then have it passed back along with the reply message.
My sneaky hunch is that the CICS Bridge will just flop the MsgID into the CorrelID and that all other values are then defaulted, instead of copied from request message.
Possible solutions:
1. Build my own bridge.
2. Store the info in a database, and retrieve on the return.
In order to avoid the effort/performance hits, I am open to suggestions!
Any clever ideas out there?
Thanks in advance,
Todd |
|
| Back to top |
|
 |
| bob_buxton |
| Posted: Mon Nov 25, 2002 9:06 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
I am not sure that I understand either the question or what you are trying to do. 
The MQ-CICS bridge, like most applications, will send its reply message to the reply to queue and queue manager in the input message.
If the reply to qmgr is A the message will go straight to A without going through WMQI on B whilst if it is B then it will go to B.
What is the function of WMQI in this scenario?
The CIH header is copied from input to output but MQCIH-RESERVED fields are not intended for passing information. 
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Nov 25, 2002 9:10 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well if you pass along the qmgr Name from QMGR A and the reply to q you want for QMGR B(WMQI) and create a qmgr alias on C with the name of QMGR A with a RMQNAME of QMGR B and XMITQ QMGR B, then it will return it to to your WMQI Box.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Mon Nov 25, 2002 9:21 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Bob:
A bit of clarification.
1. WMQI transforms XML to COBOL for the request message.
2. Converts COBOL to XML on the reply.
The reply message will be returned to QMGR B, but the trick is having available for WMQI which QMGR it should be replying to. It has lost the track that this message should be sent to QMGR A.
I was hoping to have WMQI, in the request message, hide this value, as an example, in ApplOriginData (MQCHAR4). Then, if the CICS Bridge preserved this value on the reply, it would be rather simple in WMQI to get it back to the right spot.
I guess my question, in a nutshell is whether any values are preserved from the original message. (Other than the New.CorrelID = Old.MsgID).
I was hoping New.ApplOriginData = Old.ApplOriginData
I suspect that the answer is no, but I had to check.
Thanks. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Nov 25, 2002 9:42 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well that is a little different than I read from the first message, there
are a couple of plugin nodes to help with this issue,
See Web Site
http://www-3.ibm.com/software/ts/mqseries/txppacs/ia09.html
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Mon Nov 25, 2002 11:10 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Took a peak at that Support Pac. It looks like it stores the ReplyToQ. I know the queue name for the message, but not the Queue Manager name. Close, but not quite. It does give me another possibility in writing a similar plug-in, but storing the queue manager name instead of the queue.
Thanks!  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 25, 2002 6:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We do this all the time.
Before I get into the three options we have used, 1 point of clarification. The bridge respects the values that you set in the MQMD_Report field, where you can tell a replying app how to handle the MSG_ID and CORREL_ID. You can tell the bridge to pass the message id to the correl id, or the correl id to the correl id, etc.
Back to the original problem. If QMA1, QMA2, or QMA3 all send messages thru WMQI on their way to CICS, how does the reply WMQI flow know which QMA to send the reply back to.
1.) Add an application specific header into the body of the message that holds the original reply to info. This header is passed from QMA* to QMB to QMC back to QMB and finally back to QMA*. This requires application changes and in your case probably is not possible, since you are using the bridge.
2.) The WMQI Request flow (going to the bridge) grabs the Message ID, Correl ID, Reply2Queue and Reply2QueueManager of the Request message and puts that info into a queue (ReplyInfoMessage). It then changes the replyto info to be that of its input queue for the reply flow. When the reply flow picks up a message, it uses its correl id to look in the queue for the corresponding ReplyInfoMessage that tells WMQI where the original request wanted the reply to go. It then does a PUT to the correct QMA*. This method requires a support pac to allow the reply flow to do a MQGET from the ReplyInfoMessage queue mid flow. This supportpac may or may not be around a year from now, or work with WMQI 3.0, etc. You get the picture.
3.) Same as #2, but you write the reply info to a database instead of a queue. This is the method we use. We have a database with 4 columns. We place the request messages IDs and Replyto info into this DB, and the reply flow reads the DB to find out where the reply needs to go. If designed properly, the Apps on QMA* / QMC don't need to do a single thing differently. All combinations of passing message ids and correl ids can work if you code the WMQI part correctly.
Do not start using fields in the MQMD for this. There is no guarantee that a future version of MQ won't need them for something else. Or maybe a field you choose today as not used will tomorrow be needed for its real purpose. And both apps on QMA* and QMC now need to be aware of your scheme, and code accordingly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Tue Nov 26, 2002 1:21 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| wmqiguy wrote: |
Took a peak at that Support Pac. It looks like it stores the ReplyToQ. I know the queue name for the message, but not the Queue Manager name. Close, but not quite. It does give me another possibility in writing a similar plug-in, but storing the queue manager name instead of the queue.
Thanks! |
I have never used the support pack (I don't work with WMQI) but I would be very suprised if it didn't also store the replyto queue manager name.
Reply to queue name is not much use without the associated qmgr name so often people mean both fields when they refer to reply to queue.
If it really doesn't store the qmgr name you could request that Neil Kolban enhance the support pac.
Storing both components of the reply to queue using the Support Pac or a database would save your WMQI nodes having any dependence on hard coded queue names which may have benefits for future flexibility and code reuse.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Tue Nov 26, 2002 5:26 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Thanks for all of the replies.
I was afraid of that database answer.
I've used database hits before and I am a bit
weary of the overhead as we start to scale up.
I'll play with the support pac and see what happens. Then as
a last resort, I will move to the database solution.
Again, thanks.
Todd |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 26, 2002 6:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
fyi, the database connection stays up, and in our tests, reading writing to the queue using the support pac was only a few milliseconds (5-7) faster than going to the database. We are doing 25,000 messages a day currently, expecting to reach over 100,000 eventually.
Just make sure the powers that be at your place realize using the supprt pac in production exposes you to the (remote in my opinion) possability of relying on something that may not be supported in the future.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 18, 2003 5:56 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
As of version 5.3.1 for the mainframe (available sometime in MArch), option one up above become viable, because you can now pass aditional headers into the IMS and CICS bridge. It ignores the additional headers (up to around 600 additional bytes worth), but maintains them to be passed back unaltered with the reply messsage.
Expiry is also respected by the bridge at 5.3.1 if the correct flag is set in the IIH header. Finally.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Feb 19, 2003 1:10 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Unfortunately the additional header support is only for the IMS bridge.
It wasn't added to the CICS bridge in 5.3.1.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 19, 2003 4:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Right. Sorry about that. The Respecting of the Expiry value is what got released for both IMS and CICS. The additional headers is only IMS.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
