| Author |
Message
|
| ALCSALCS |
 Posted: Mon Jul 28, 2014 1:59 am Post subject: General question about Websphere MQ Publish Subscribe |
 |
|
Acolyte
Joined: 14 Apr 2002
Posts: 61
|
We were intending to use the PUB/SUB to duplicate a message being delivered to one queue to two queues. In general, this works fine and the data part of the message is an identical copy.
We now realise that the application putting/reading the original message uses the correlid.
Additionally the PUB/SUB engine also uses the correlid, so the application cannot now rely upon this correlid field to read respones to the original messages.
So basically the question is, has anyone managed to find a way around this to achieve what we require as described above using PUB/SUB or its just known that if you use the correlid in your application then PUB/SUB is not a viable solution since it uses the correlid?
Many thanks in advance for any help or suggestions. |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Jul 28, 2014 2:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
|
| ALCSALCS |
| Posted: Tue Aug 12, 2014 3:21 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2002
Posts: 61
|
Hi All,
We managed to find a solution / way around this to preserve the correlid set by an application when using PUB/SUB.
What was done is as follows;
Simply set the correlid parameter for the Subscription to zeroes.
Then any messages sent will have their correlid preserved. Not sure why this is not documented, or at least we didn't find any documentation.
Hope that helps anyone else trying to achieve the same as we did.
Thanks. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 12, 2014 3:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Version? commands used?
_________________
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 |
|
|
| ALCSALCS |
| Posted: Tue Aug 12, 2014 4:08 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2002
Posts: 61
|
The MQ version we have is MQ V7.0.1.12
The command used to change was;
ALTER SUB(subscription name...) DESTCORL(00)
or much easier to change using MQ Explorer.
Thanks. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 12, 2014 5:27 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
And this behaviour is definitely different to just omitting the DESTCORL parameter?
If so, I suggest you raise a documentation APAR via a PMR with IBM.
It's not ideal to rely on an undocumented feature.
_________________
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 |
|
|
|
|
