| Author |
Message
|
| Chas |
 Posted: Mon Feb 17, 2003 1:57 pm Post subject: Taking messages off an intermediate queue manager |
 |
|
Newbie
Joined: 04 Oct 2002
Posts: 5
|
Sorry if the title is a little confusing.
I have a configuration where I have three queue managers in sequence - the first queue manager sending to the third via the second etc. - and messages back again. The second queue manager is used as a 'hop' between firewalls with only transmission queues.
What I would like to do is remove messages from the second queue manager, amend them and forward them on to recipient queue manager (i.e. one or three).
Is there anyway of safely doing this without changing the configuration of the 1st and 3rd queue managers ? |
|
| Back to top |
|
 |
| clindsey |
| Posted: Mon Feb 17, 2003 3:12 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
Depending on your environment, you may be able to write an apiexit to intercept the mqget of the xmit queue and make the changes.
The apiexit is available on the distributed platforms, nt/2000/xp,aix,solaris,linux, and hp.
You can find more on the apiexit in the MQ 5.3 Application Prog. Guide.
Also, there is a sample <mqtop>\tools\c\sample\amqsaxe0.c
Charlie |
|
| Back to top |
|
|
| pgorak |
| Posted: Tue Feb 18, 2003 1:41 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
| Quote: |
| Is there anyway of safely doing this without changing the configuration of the 1st and 3rd queue managers ? |
Yes, if you can change definitions on the 2nd queue manager. An obvious approach would be to have an application on the intermediate (the 2nd) queue manager that would get messages from a local queue, do something with application data and send them to the target queue manager.
By the way, Charlie: unless the intermediate queue manager is on OS/390, I don't see a way to apply an API-crossing exit. Could you expound on the topic, please?
Piotr |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 18, 2003 5:21 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Piotr,
API crossing exits are available in the distributed platforms as of version 5.3.
Chas,
If you absolutly can't change QM3 or QM1's definitions, which is the better solution....
QM2 has an XMIT queue called QM1, for messages that are destined for QM1. Change the XMIT queue called QM1 to a plain local queue. Messages will accumalate in that queue due to name resolution. An app on QM2 will read the messages and change them.
Define a new XMIT queue to QM1 called QM1.XMITQ. Create a remote queue def on QM2 pointing to the final queue on QM1, and in this remote queue def, specify the XMIT queue to be used as QM!.XMITQ.
Do the same in reverse for QM3.
UGH.  Anytime you need to send message between QM1 and QM3, they will be forced through this convaluted mess. You will have to add new remote queue defs on QM2, and possibly modify that middle app to handle the new messages. But it will work.
You are much better off having the apps on QM1 or QM3 put to remote queue defs that you can then point wherever (either directly to queues on QM1/QM3, or to the middle app's queues on QM2).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Chas |
| Posted: Wed Feb 19, 2003 2:39 am Post subject: |
|
|
Newbie
Joined: 04 Oct 2002
Posts: 5
|
| Many thanks for all the replies - the impression I get is that (though there are other options) - the best option would be to change the overall design so QM1 remote defs q's deliver to local queues on QM2 (to be processed by the app), and then the app would place data on remote def q's on QM2 delivering to QM3 ? |
|
| Back to top |
|
|
| leongor |
| Posted: Wed Feb 19, 2003 3:24 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
You can change definitions only on QM2 using qmgr aliases :
| Quote: |
delete ql(QM1)
delete ql(QM3)
def qr(QM1) rqmname(QM2)
def qr(QM3) rqmname(QM2)
delete ql(QM1.XMIT) usage(XMITQ)
delete ql(QM3.XMIT) usage(XMITQ)
def ql(OrigDestQonQM1)
def ql(OrigDestQonQM3)
def qr(DestQonQM1) rqmname(QM1) rname(OrigDestQonQM1) xmitq(QM1.XMIT)
def qr(DestQonQM3) rqmname(QM3) rname(OrigDestQonQM3) xmitq(QM3.XMIT)
|
Thus all messages will remain in QM2 for your application will amend them.
After that they can be forwarded via remote queues to original destination.
By the way, the solution with changing xmitQ to usage normal won't work.
Messages will get to deadQ with rc=2092 (XMIT_Q_TYPE_ERROR).
Another way to handle the situation is to use channel message exit on QM2
to invoke your application before the message is sent to remote qmgrs.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 19, 2003 5:04 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Leonid is correct about my solution not working 100% if you just change QM1 / QM3 to a local queue that is not an XMIT queue. They would indeed go to the DLQ. You need the QMAlias trick like he suggested.
I think Leonid meant:
def ql(QM1.XMIT) usage(XMITQ)
def ql(QM3.XMIT) usage(XMITQ)
not:
delete ql(QM1.XMIT) usage(XMITQ)
delete ql(QM3.XMIT) usage(XMITQ)
Yes Chas, it is prefered if possible to make remote queue defs on QM1 and QM3. Even though using QM Aliases will make this work for this app, realize that that solution means any messages going through QM2 on their way to QM1 / QM3 will get caught in this, meaning as new apps come up on QM1 / QM3 that use new queues, you will always have to be making changes on QM2 as well (which you would not have to do if you just make the remote queue defs on QM1 /QM3 to begin with).
If this is the only app that will ever use QM1/2/3, then no big deal. If you expect a lot more apps in the future with lots of new queues, you are setting yourself up for more admin work then necessary.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| leongor |
| Posted: Wed Feb 19, 2003 9:10 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Thanks for noticing Peter.
By the way, I don't agree about more admin work with this way of configuration.
Just instead of defining remote defs on QM1 or QM3 you'll define them on QM2.
I mean, if in the future will be new kind of messages without need for application to amend them
then just remote queue defs need be defined with the real original names instead of locals.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
|
|
