| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Local Address(LOCLADDR) in CLUSTER CHANNEL definitions |
« View previous topic :: View next topic » |
| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Jun 13, 2013 7:08 am Post subject: Local Address(LOCLADDR) in CLUSTER CHANNEL definitions |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I found this in the MQ 7.5 info center
| Quote: |
| When a LOCLADDR value is specified, a channel that is stopped and then restarted continues to use the TCP/IP address specified in LOCLADDR. In recovery scenarios, this attribute might be useful when the channel is communicating through a firewall. It is useful because it removes problems caused by the channel restarting with the IP address of the TCP/IP stack to which it is connected. |
With respect to a CLUSSDR I may not understand its usefulness in a recovery or any other scenario (I am used to MQ servers which have only 1 IP in the IP Stack). If the server had a stack of available IPs, would the IP range need to be specified in LOCLADDR in order for any usefulness to be realized? - in which case the IP stack could be used to enhance availability of the channel? Also, I fail to see any potential usefulness in specifying LOCLADDR on a CLUSRCVR - Are there any Grand Poobah's out there that possess a clear explanation of the usefulness of LOCLADDR specified on various CHLTYPEs ? |
|
| Back to top |
|
 |
| mvic |
| Posted: Thu Jun 13, 2013 5:42 pm Post subject: Re: Local Address(LOCLADDR) in CLUSTER CHANNEL definitions |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ivanachukapawn wrote: |
| With respect to a CLUSSDR I may not understand its usefulness in a recovery or any other scenario (I am used to MQ servers which have only 1 IP in the IP Stack). If the server had a stack of available IPs, would the IP range need to be specified in LOCLADDR in order for any usefulness to be realized? - in which case the IP stack could be used to enhance availability of the channel? Also, I fail to see any potential usefulness in specifying LOCLADDR on a CLUSRCVR - Are there any Grand Poobah's out there that possess a clear explanation of the usefulness of LOCLADDR specified on various CHLTYPEs ? |
It is OK to ask IBM to clarify their documentation. It sounds like you got confused by the bit you quoted (so did I). So, submit a feedback saying how you got confused by it.
What is it you are trying to implement? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 13, 2013 7:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
On an autodefined cluster sender the Local Address field is typically filled in by a Channel Definition (CHAD) exit. For obvious reasons.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 14, 2013 5:31 am Post subject: Re: Local Address(LOCLADDR) in CLUSTER CHANNEL definitions |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
I found this in the MQ 7.5 info center
Also, I fail to see any potential usefulness in specifying LOCLADDR on a CLUSRCVR? |
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/ic11740_.htm
| Quote: |
IP addresses must not be put in the LOCLADDR field of a CLUSRCVR channel, unless all queue managers are on the same machine.
If a cluster must use LOCLADDR to get the outbound communication channels to bind to a specific IP address, write a Channel Auto-Definition Exit. Doing so forces the LOCLADDR value into any of their automatically defined CLUSSDR channels and specifies it in the manually defined CLUSSDR channel.
|
Maybe all the servers in your shop have 2 IP addresses, 1.2.3.* and 5.6.7.*. Maybe you want all MQ CLuster traffic to use the 5.6.7.* addresses exclusively for inbound and outbound, so you could use LOCLADDR on your cluster channel in this weird situation.
| ivanachukapawn wrote: |
| If the server had a stack of available IPs, would the IP range need to be specified in LOCLADDR in order for any usefulness to be realized? |
Would it need to be? Not always. But it might. If you have a SNDR channel going to another queue manager thru a firewall, and your QM is on a system where multiple IPs are possible, the firewall dudes will probably want to open the outgoing hole based on a specific source IP address from your QM, and not open it for a bunch of potential source IPs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jun 15, 2013 6:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I've used the LOCALADDR param when specifying the TCP/IP hand-off port range.
When to connect to a QM using the Listener Port once the connection is established (or during this process) an unused port is used for future connectivity.
In the case where there is a firewall in the way that limits this process you have to allow the hand-off to use a defined set of ports. This does just that.
I have to admit that this is a pretty rare condition but one that I have encountered a lot more recently as people get better about locking down ports in firewalls OR using a CISCO Switch as a poor firewall and in this case it can't handle the IP Hand off(SIGH)
Some CISCO certified people don't understand this process and think that all communications is handled over the initial connection port. I guess that this is covered in the more advanced teaching modules.
note: I call it the 'hand off process' as it help me understand it. I might have the wrong name for it so if I have then please go easy on me.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| 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
|
|
|
|
