| Author |
Message
|
| vibhu007 |
 Posted: Tue Aug 30, 2005 4:16 pm Post subject: copying a message |
 |
|
Newbie
Joined: 29 Aug 2005
Posts: 6
|
Hi,
I have a requirement where a message put on a queue(Q1) should get copied to one more queue(Q2). Any idea how this can be achieved.
This is on unix.
Thanks. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Tue Aug 30, 2005 4:22 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
look at the mq docs for "Distribution Lists"
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 30, 2005 4:45 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Several options:
1. Use a distribution list - In the sending application, instead of MQOPENing one queue, you open a list containing both, and when you MQPUT to the list the same message is sent to both. Read the Programming Guide on how to use distribution lists.
2. In the sending application - open two queues, MQPUT twice the same message...
3. If, for some reason, you cannot change sending application code do the following: Say you had application APPLA sending to Q1 on remote qmanager QM, this is done with a remote queue called QR1 and a transmission queue called TO.QM (these are terrible names, just for this example, never to be used again).
What you do is change QR1 so that it is directed to a new local queue called TOQ1, create another remote queue called QR1REAL which is defined like QR1 was defined before, and define QR2 to Q2. Write a small application (about 10 lines) which simply reads everything in TOQ1 and sends it to QR1REAL and to QR2 using either destination lists or two MQPUTs. No code changes to application.
So if once the flow looked like this: APPLA -> QR1 -> TO.QM (transmission) -> Q1
It will now look like this: APPLA -> QR1 -> TOQ1 (local) -> splitting application -> put to QR1REAL and QR2 -> TO.QM and Q2
You should only use this solution if it is only temporary, otherwise change the sending application. It is not exactly a "robust" solution, but merely a patch, and patches tend to unweave...
4. If you meant (it is not clear from your post) real message duplication only AFTER the message is in Q1, then simply have the application reading that queue MQPUT every message it MQGETs under syncpoint.
There are probably other options, but I haven't enough info on your problem to offer more. |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Aug 30, 2005 6:09 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Search for MirrorQ.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 30, 2005 6:41 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
MirrorQ is a message exit and a lot of people use it.
Years ago, I wrote a program called: mmx (Message Multi-Plexer). It is a simple program to move a message from a source queue to 'n' target queues (replicates MQMD & data). You can download it and the 'C' source for it from:
http://www.capitalware.biz/mq_code_c.html
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Aug 31, 2005 7:10 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| paulgroo |
| Posted: Fri Sep 02, 2005 6:16 am Post subject: |
|
|
Centurion
Joined: 07 Jul 2005
Posts: 138
Location: Ireland
|
| I have this workiong on a system here. I have created a shadow queue that gets a copy of everything that gets sent to the main queue. I had to create an Initiation Queue and Process Triggerbut it works fine. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Sep 02, 2005 7:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You could also write a small "broker" application to read an input queue and write the messages to two output queues, that way the original applications do not have to be changed (which is sometimes more trouble that it's worth).
If you have the IBM Message Broker - a message flow to do this could be developed in a few minutes, otherwise use a programming language. |
|
| Back to top |
|
|
| vinoth |
| Posted: Fri Sep 02, 2005 9:56 pm Post subject: |
|
|
Apprentice
Joined: 03 Mar 2005
Posts: 31
|
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Sep 03, 2005 5:20 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| vinoth wrote: |
| Simplest of all is using the q utility given by IBM, just define the q utility in the process definition, and call it once a message appears in ur main queue. |
First of all, I would like to emphesize this is not reallt "given by IBM" but just "may be downloaded from IBM's site" - this is a category 2 support pack, which means
| IBM wrote: |
Technical support
Category 2 SupportPacs are provided in good faith and AS-IS. There is no warranty or further service implied or committed and any supplied sample code is not supported via IBM product service channels. |
So one cannot use unlicensed progs, or simply doesn't trust them, he shouldn't use this solution. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Sep 03, 2005 5:38 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| vinoth wrote: |
| Simplest of all is using the q utility given by IBM, just define the q utility in the process definition, and call it once a message appears in ur main queue. |
Second, there are a few small probs with ma01 concerning the given scenario: naturally you'll want to start it using the runmqtrm, thing is it doesn't receive parameters like runmqtrm supplies them - so you'll have to hardcode the queue, qm and other parms in the PROCESS def. This is OK, but if you have more than one queue from which you wish to duplicate, then you'll have to have another trigger monitor - one for each such queue.
A good solution for this would be to write a batch file, which receives parameters in the order given by runmqtrm and translates to the parmameters which ma01 expects.
Another option is using "-*" which supposedly should do an endless loop MQGETting the queue, but for some silly reason asks you each time "Do you want to connect again (y/n) ?" - however you can simply create a file with 100000 "y"+CR\LF and send it to standard input.
I had just downloaded it, so if i'm wrong about anything I will happily stand corrected. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 03, 2005 7:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hopsala wrote: |
| vinoth wrote: |
| Simplest of all is using the q utility given by IBM, just define the q utility in the process definition, and call it once a message appears in ur main queue. |
Second, there are a few small probs with ma01 concerning the given scenario: naturally you'll want to start it using the runmqtrm, thing is it doesn't receive parameters like runmqtrm supplies them - so you'll have to hardcode the queue, qm and other parms in the PROCESS def. This is OK, but if you have more than one queue from which you wish to duplicate, then you'll have to have another trigger monitor - one for each such queue.
A good solution for this would be to write a batch file, which receives parameters in the order given by runmqtrm and translates to the parmameters which ma01 expects.
Another option is using "-*" which supposedly should do an endless loop MQGETting the queue, but for some silly reason asks you each time "Do you want to connect again (y/n) ?" - however you can simply create a file with 100000 "y"+CR\LF and send it to standard input.
I had just downloaded it, so if i'm wrong about anything I will happily stand corrected. |
Why more than one trigger monitor. I thought it would suffice to have one process for each queue concerned and when starting it in the background you could have more than one queue using the same trigger monitor.
Am I being naive or missing something there ? |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Sep 04, 2005 1:27 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Hm, you are generally right, but I just did a re-check of this and there's another prob: The runmqtrm activates progs with the following parms "<ApplId> <MQTMC2> <EnvData>", so theoretically you should be able to create a process with ApplId="q.exe -m QMNAME -i INQNAME -o OUTQNAME. Thing is, ma01 does not accept redundant parameters, so the MQTMC2 does not let the executable run (you get a "usage" printout)
There is a silly workaround - putting in the PROCESS ApplId="q.exe -m QMNAME -i INQNAME -o OUTQNAME | echo " or something similar, thus the MQTMC2 is sent to echo and is effectively ignored.
With all that in mind, you're right on the dot - no need for two trig monitors, just two process defs; I err, am only human y'know 
(As said, had only d/l ma01 after vinoth's post) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 04, 2005 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hopsala wrote: |
| There is a silly workaround - putting in the PROCESS ApplId="q.exe -m QMNAME -i INQNAME -o OUTQNAME | echo " or something similar, thus the MQTMC2 is sent to echo and is effectively ignored. |
I'd probably go for a shell script that ignores the MQTMC2 (%1| ${1}) parameter and passes the subsequent ones...
| Code: |
# case 1
# move the parm list 1 to the left
shift
# pass all remaining parms and start in background
start q.exe %*
# alternatively case 2
start q.exe %2 %3 %4 %5 %6 %7 %8 %9
|
Please forgive any Unix/MS DOS differences. |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Sep 05, 2005 7:06 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Agreed, that's why I said a few posts back that the best solution is a batch file; however, it is always better to post the actual code than talking about it (a code snippet is worth a thousand words) - future generations thank you  |
|
| Back to top |
|
|
|
|
