| Author |
Message
|
| mchillin |
 Posted: Tue Oct 10, 2006 12:01 am Post subject: Rfhutil Message Id |
 |
|
Novice
Joined: 27 Sep 2006
Posts: 16
|
When writting a message to an MQ queue is it possible to maintain the message Id rather than it being changed everytime the message is written to the queue?
We have tried using the "save Msg Id" and the "restore Msg Id" but everytime the message is written the message id is changed. The Rfutil pdf does not appear to expand of the matter.
It is vital that we maintain the original message id for the next steps in the process.
We would appreciate any advice.
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 10, 2006 12:12 am Post subject: Re: Rfhutil Message Id |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mchillin wrote: |
It is vital that we maintain the original message id for the next steps in the process.
|
Question - why do you need to put messages with duplicate message ids? 
Duplicate Correlation IDs maybe, but msg ids? Why not use grouping?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mchillin |
| Posted: Tue Oct 10, 2006 12:20 am Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 16
|
We are not duplicating the message id. The save and restore options were only used to test to see if we could maintain what we entered as the input.
All we want is that the message id that we enter as input is not changed by Rfhutil when writting the queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 10, 2006 12:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
AFAIK Rfhutil uses the MQ_PMO_NEW_MSG_ID option so a new Id is always generated. You could generate an equivalent test harness that doesn't without too much trouble.
As a best practice point (which of course may be overriden by your requirements) it's usually better to allow MQ to generate new message ids. There's been some discussion on this on the forum (one thread quite recently) which you may wish to search for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 10, 2006 3:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mchillin wrote: |
We are not duplicating the message id. The save and restore options were only used to test to see if we could maintain what we entered as the input.
All we want is that the message id that we enter as input is not changed by Rfhutil when writting the queue. |
Why use read and write? why not use browse. RFHUtil supports browse. In this way you do not modify in anyway the message.
If you use write, the message gets another messageId and IS another message. So it should have a different messageId. You need to be able to handle that case...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mchillin |
| Posted: Tue Oct 10, 2006 4:01 am Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 16
|
| Thanks.. but the object is to able to browse one queue and then be able to write the message to another queue without the message id changing when we perform the write. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 10, 2006 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Again I ask why? As fjb_saper points out, to write a message is to create a new message which should properly have a new message id.
Struggling to see the requirement here....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 10, 2006 4:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is probably some kind of message administrative function, where messages need to be moved from one queue to another - either for problem resolution or for some such.
I'd suggest that maybe RFHUtil isn't the tool for this, or that perhaps the options being used are wrong and some more time reading the documentation might help. I'm not saying it *can* be done with RFHUtil, mind you.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 10, 2006 3:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you just want to move the message I would use MO71. Don't know though if it would preserve the message Id...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mchillin |
| Posted: Tue Oct 10, 2006 10:30 pm Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 16
|
The message and message id are created using MB, these have to be maintained as it is a requirement of a third party, in which we send the message id and they return it as the correl id, which then consequently allows the routing of the message via one message flow or another.
The need to be able to browse the message from a queue and then write it again without changing the message id is either; when there is an error in the message and it has to be repaired and the other being the change of environment of the message for example (DEVELOPMENT to INTEGRATION).
This is a temporary problem as we are creating programs in z/OS which leave the messages in MQ queues, but it is of interest to see if there is a way of doing so with Rfhutil.
Thanks for your replies. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 11, 2006 3:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you change environment I would say you need to restart your flow at the beginning and that would take care of your problem...
On the other hand if your 3rd party app is "well behaved" the message id should be of little importance: i.e. in a "well behaved" app in the request reply model the behavior is:
- There is no correlationId ==> the reply.correlationId=request.messageId
- There is a correlationId ==> the reply.correlationId = request.correlationId
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
