| Author |
Message
|
| scar |
 Posted: Thu Oct 23, 2014 6:28 am Post subject: Segregating messages in XMITQ |
 |
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
We are using MQ 7.0.1
We have stopped the sender channel due to an application issue and let a ton of messages accumulate.
We have a scenario where we need to hold back certain messages that are sitting in the XMITQ.
We need to hold back certain messages based on the content, and let the rest of them go.
After a while we can resend the messages that were held back earlier.
How can I accomplish this ??
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Oct 23, 2014 6:36 am Post subject: Re: Segregating messages in XMITQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scar wrote: |
| How can I accomplish this ?? |
Unload the queue with q, qload or a similar utility of your choice to a file.
Separate the message into 2 files based on content using any file sorting utility of your choice.
Load the messages you want to send back into the queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 23, 2014 6:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
MO71 (and of course the underlying qload) can unload selectively (for example searching for a certain string in the message).
Also you can choose to remove the unloaded messages (as they are unloaded).
The first thing to do is take a full unload of the xmit queue in case you mess up anything.
How are you distinguishing between wanted and unwanted messages - and are we talking about dozens, hundreds, or thousands etc?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Oct 23, 2014 7:13 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
| Personally, I would want to push the responsibility of removing messages on a queue onto the application team, if at all possible. However, I also understand that sometimes desparate times call for desparate measures. |
|
| Back to top |
|
|
| scar |
| Posted: Thu Oct 23, 2014 7:19 am Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
At least there will be thousands of messages, we can differentiate between the messages based on some field values in the message content.
Can I use rfhutil ?
I need to be able to do this programmatically(Java based) , based on parameters passed to the program
Can I read all the unwanted messages and write them to a file and delete them from the XMITQ ?
Once the channel is opened and the messages in the queue are transmitted, can I read the earlier file and write them to the XMITQ again ?
It's a stupid question, but just need to see if there is a way...
Can I have multiple sender channels pointed to the same receiver channel ?
In the sense instead of sending all the messages to the same transmit Q and sender channel, can I send them through different XMITqs and channels, even though to the same destination... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 23, 2014 7:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
An XMITQ is just a QLOCAL.
You can read messages on an XMITQ with any program that can issue an MQGET.
Messages on an XMITQ have an XMIT header on them. I forget if this is fully documented or not. Go check the knowledge center.
Information in the XMIT header identifies the remote qmgr and remote queue.
So you can write a program that reads a queue (that happens to be an XMITQ) and then uses information either in the message itself or in the XMIT header to determine where or whether to write the message again.
You should plan on this program removing the XMIT header before it puts the message, so that proper name resolution can be handled and that the queue manager will reconstruct the new and correct XMIT header. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 23, 2014 7:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scar wrote: |
| Can I use rfhutil ? |
rfhutil can write messages to a file.
| scar wrote: |
| I need to be able to do this programmatically(Java based) , based on parameters passed to the program |
The only abilities any utility has to read selectively are the ones already mentioned. If you need more than that, you're problably better off writing your own (Java based) utility.
| scar wrote: |
| Can I read all the unwanted messages and write them to a file and delete them from the XMITQ ? |
If you're reading the messages off the queue then that deletes them like any other MQGet operation. I echo the advice of my most worthy associate to take a full copy of all the messages before attemtping this.
| scar wrote: |
| Once the channel is opened and the messages in the queue are transmitted, can I read the earlier file and write them to the XMITQ again ? |
Of course. You're just putting messages on a queue.
| scar wrote: |
| Can I have multiple sender channels pointed to the same receiver channel ? |
Yes.
| scar wrote: |
| In the sense instead of sending all the messages to the same transmit Q and sender channel, can I send them through different XMITqs and channels, even though to the same destination... |
Yes. Why would you want to?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 23, 2014 7:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| scar wrote: |
| Can I have multiple sender channels pointed to the same receiver channel ? |
Yes. |
Umm.
Really? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 23, 2014 7:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I would avoid RFHUTILC - because you may not get the messages reloaded exactly as they were before.
Use MO71 (qload) to ensure the reloaded messages are absolutely identical to how they were originally.
To be honest, this is a job for an expert, or someone with time to practice.
Don't forget to remove the get inhibit on the xmit queue.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 23, 2014 8:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| scar wrote: |
| Can I have multiple sender channels pointed to the same receiver channel ? |
Yes. |
Umm.
Really? |
I never said from the same queue manager..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 23, 2014 8:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| Vitor wrote: |
| scar wrote: |
| Can I have multiple sender channels pointed to the same receiver channel ? |
Yes. |
Umm.
Really? |
I never said from the same queue manager..... |
It's true, you didn't disclaim that.
Nor whether or not more than one of them could be running at the same time... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 23, 2014 8:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Nor whether or not more than one of them could be running at the same time... |
2 sender channels from 2 different queue managers pointing to 1 receiver channel gets you 2 receiver MCAs with 2 sets of sequence numbers and all the other good things.
Works fine and I leave the drawbacks of such a system (which I've seen used) as an exercise for the readers. Suffice it to say it's not a best practice, hence "why would you want to?"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Oct 23, 2014 9:00 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
| Vitor wrote: |
| 2 sender channels from 2 different queue managers pointing to 1 receiver channel gets you 2 receiver MCAs with 2 sets of sequence numbers and all the other good things. |
As Barny from Mayberry would say, "Two times two is four". I think you meant 1 sender channel from each of two Qmgrs.... bla bla bla... 
@ the OP,
As you have been told, qload is probably the magical silver bullet your going to get barring writing your own. It is well worth understanding this support pac. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 23, 2014 9:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Vitor wrote: |
2 sender channels from 2 different queue managers pointing to 1 receiver channel gets you 2 receiver MCAs with 2 sets of sequence numbers and all the other good things.
Works fine and I leave the drawbacks of such a system (which I've seen used) as an exercise for the readers. Suffice it to say it's not a best practice, hence "why would you want to?" |
I would not want to, except when it is a cluster sender pair going against a cluster receiver...
Sorry just being thorough here 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| scar |
| Posted: Thu Oct 23, 2014 9:41 am Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
Understood, will write some sample code to check it out.
Thanks for all your help. |
|
| Back to top |
|
|
|
|
