| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Sender channel behaviour when intercommunicating with TPF |
« View previous topic :: View next topic » |
| Author |
Message
|
| jhalstead |
 Posted: Tue Dec 03, 2002 7:04 am Post subject: Sender channel behaviour when intercommunicating with TPF |
 |
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Quite an interesting problem, I'm communicating with a TPF system over standard sender/receiver channel pairs. The TPF system has many IP addresses, so when I connect through the DNS I can get resolved to different IP addresses each time - I believe it round robins throught those in use. These IP addresses all relate to the same TPF processor and QueueManager.
Now when I first create the channels and fire them up all is well. However after a period of time (discint) and no messages being sent to TPF the channel will go to an inactive state.
When the next message arrives on the transmission queue it triggers the sender channel to TPF into a running mode and attempts to send the message. Now likely as not I get resolved to a different IP address, there is no saved channel status for this sender channel / IP address combination so the sender thinks it's sending it's first message - however TPF thinks the sequence number should be higher.... So message not accepted, channels in doubt - sequence number mismatch. This needs resolve and reset commands to be issued at my end.
Once these commands are issued all is well until the channel goes inactive ... Then it starts again!
This is a new one on me as it's my first ineraction with TPF. I didn't know that the saved state of sender channels were stored by both channel name and conname. Do you think my interpretation of this behaviour is sound?
Now to a resolution: The two I can think of are:
1) Set discint to 0. Not ideal, my end or TPF end went down we'd still need to do the resolve/reset - however it'd be less frequent.
2) Rather that use the DNS, use a single IP address. This will work just fine after the hosts go down - however if the network card relating to the IP I choose goes down I have to either wait for it to be fixed or change the conname parameter on my channel and then resolve/reset.
Any other ideas?
Many thanks
Jamie |
|
| Back to top |
|
 |
| jhalstead |
| Posted: Thu Dec 05, 2002 12:37 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
| Anyone got any thoughts whatsoever? I'd really appreciate any feedback .... Not that I'm desperate .... OK! I am. Happy Now? |
|
| Back to top |
|
|
| mikepullen |
| Posted: Mon Feb 03, 2003 5:36 am Post subject: |
|
|
Newbie
Joined: 03 Feb 2003
Posts: 3
Location: London, UK
|
Jamie,
I guess by now you know about the solution, but in the remote chance that someone else wants to know, here's the answer from IBM.
The sequence number problems are almost certainly due to
the v2.x MQSeries code on the TPF side. v2.x MQSeries channels store
their sequence number information keyed off the IP address of the
remote system, while v5.x MQSeries and WebSphere MQ channels access
their sequence number information based on the remote queue manager
name. As long as the TPF queue manager is returning variable IP
addresses to the UNIX queue managers these errors will persist.
SupportPac MS05 used to provide a security exit called QMCONN which
changed the synchronisation key information exchanged by v2.x MQSeries
channels to use the queue manager name instead of the IP address. The
MS05 SupportPac has since been withdrawn and is no longer available,
but in this case I believe it would be the appropriate solution. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
