| Author |
Message
|
| nikhil.laghave |
 Posted: Mon Nov 12, 2007 10:52 pm Post subject: error in joining a queue manager to a cluster |
 |
|
Newbie
Joined: 09 Mar 2007
Posts: 5
Location: Pune, India
|
Hi,
I want to join a queue manager (on linux box which is behind the firewall) to a mainframe cluster. Have created the cluster sender channel on this queue manager but the channel goes in the retrying state. On pinging the channel I get the following error :
ping CHANNEL(XXXX)
3 : ping CHANNEL(XXXX)
AMQ9213: A communications error for TCP/IP occurred.
The following was seen in the error logs:
13/11/07 06:04:47 - Process(29926.533) User(mqm) Program(amqrmppa)
AMQ9002: Channel 'XXXX' is starting.
EXPLANATION:
Channel 'XXXX" is starting.
ACTION:
None.
-------------------------------------------------------------------------------
13/11/07 06:04:50 - Process(29926.533) User(mqm) Program(amqrmppa)
AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP (connect) call was 113 (X'71'). Record these
values and tell the systems administrator.
----- amqccita.c : 1120 -------------------------------------------------------
13/11/07 06:04:50 - Process(29926.533) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'XXXX' ended abnormally.
ACTION:
Look at previous error messages for channel program 'XXXX' in the
error files to determine the cause of the failure.
----- amqrccca.c : 777 ------------------------------------------------
Can anyone help me with this ? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 13, 2007 1:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Look up the TCP/IP error and speak to your network people.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hilltops |
| Posted: Thu Nov 15, 2007 3:08 pm Post subject: |
|
|
Centurion
Joined: 01 Mar 2006
Posts: 112
|
Did you ensure that there are firewall rules set up to all the repository queue managers in cluster? Note that although you join a cluster by specifying a channel to only one of the repository queue managers,all the repository queue managers will need to be able to talk with your queue manager thru the firewall.
You may also have to add the IP/hostname of the repository queue manager machines to the /etc/hosts files on your server within the DMZ. |
|
| Back to top |
|
|
| heman malve |
| Posted: Fri Nov 16, 2007 1:36 am Post subject: follow this procedure |
|
|
Newbie
Joined: 03 Aug 2005
Posts: 7
Location: bangalore
|
Detailed Steps
Verify that the machine is at the correct MQSeries version and CSD level
The following mqver output applies to HPUX, AIX and NT
mqver:
(results should be)
Name: WebSphere MQ
Version: 530.5 CSD05
CMVC level: p530-05-L030926
BuildType: IKAP - (Production)
Note: We are waiting for a comprehensive list of versions required for the other platforms. At the moment you SHOULD NOT add a Queue Manager on Windows NT to the cluster unless it matches the above version and CSD level.
Verify that the machine is at the correct Data Junction version
See () for latest information
It is required that data junction be upgraded to a version that is able to write to a cluster queue.
Check that the machine is not already a member of the cluster
DISPLAY CLUSQMGR (<qmgr name>)
If you do not get any output then the queue manager is not part of a cluster.
Copy the auto channel definition
Binaries can be found here () (Note: that the binaries all have the same file name, you must extract from zip with full path)
Be careful on Linux. There are two versions of the CHADEXIT one for 32-bit Linux and one for 64 bit linux.
Be careful on HP-UX. Itanium HP-UX (ie IA64) has a different exit. (Use the command "uname -m" to determine the platform. This gives "ia64" for the Itanium platform.)
On windows, copy CHADEXIT.dll to the exits folder. To determine which exits folder is used for a queue manager on Windows is, execute the following command. (Note: This needs to be done due to the inconsistent nature of the installation of queue managers on windows)
regdmp HKEY_LOCAL_MACHINE\Software\IBM\MQSeries\CurrentVersion\Configuration\QueueManager | findstr /i ExitsDefaultPath
On PA-RISC HPUX, 32-bit Linux & AIX copy CHADEXIT to /var/mqm/exits/CHADEXIT (note that the permissions on this file should be mqm:mqm, rwxrwxr-x)
On IA64 HPUX copy CHADEXIT to /var/mqm/exits64/CHADEXIT (note that the permissions on this file should be mqm:mqm, rwxrwxr-x)
On 64-bit Linux copy CHADEXIT to /var/mqm/exits64/CHADEXIT (note that the permissions on this file should be mqm:mqm, rwxrwxr-x)
TIP: you can use chmod 775 /var/mqm/exits/CHADEXIT
Add the queue manager to the security exit configuration file
This must be done on both repository queue managers.
Dev: (REPOSD3 on ISXVL610 and REPOSD1 on ISXLX900)
Mirr: (REPOSM3 on ISXVL620 and REPOSM1 on ISXLX901)
Test: (REPOST3 on ISXVL610 and REPOST1 on ISXLX902)
Prod: (REPOSP3 on ISXVL620 and REPOSP1 on MTOLX044)
You should add the queue manager name to authqmgr.txt in :
"D:\Apps\Program Files\IBM\WebSphere MQ\Exits" on the NT Repository
/var/mqm/exits Linux repository
(please make sure that authqmgr.txt is owned by group mqm i.e. -rw-r--r-- 1 gerasale mqm 1839 2004-07-13 11:07 authqmgr.txt )
Alter the queue manager to include the channel autodefinition exit
ALTER QMGR CHADEXIT('CHADEXIT(ChadExit)')
Create cluster reciever channel
DEF CHL('TO.<QUEUE MANAGER NAME>') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('<connection name>(<port>)')
CLUSTER(CLUS<tier>1)
Where:
<connection name> is the dns name of the server where your queue manager run.
<port> is the port number on which queue manager listening (please check the port number, it is normally one of 1414, 1415 or 1416).
Create cluster sender channel
DEFINE CHL(TO.REPOS<tier>1) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('REPOS<tier>1.NA.MARS(1461)') CLUSTER(CLUS<tier>1)
Verify that the machine is part of the cluster
If you are really paranoid you can execute the following on the source queue manager and both the repository queue managers, but executing on the source queue manager should be sufficient.
DISPLAY CLUSQMGR('<QUEUE MANAGER NAME>')
Further checks you can do are:
1. Check that CLUSSDR channel you created is NOT in retry state.
DIS CHSTATUS(TO.REPOSP1)
2. Create a cluster queue and see that it is visible in the repository. Use the tooling procedure 'Display Cluster Queues' and run it against the repository queue manager for the cluster (both repositories if you like). |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 16, 2007 1:40 am Post subject: Re: follow this procedure |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| heman malve wrote: |
Name: WebSphere MQ
Version: 530.5 CSD05
|
Upgrade. Now. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 16, 2007 1:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
And as hilltops says, check the firewall. There's nothing in those instructions about network changes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 16, 2007 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And remember that clusters are extremely sensitive to NAT and should only work with hostnames and not IP #...
Make sure that the hostname of every cluster member ( FR or PR) is reachable from every cluster member... 
This usually means some additional entries in the DNS or the /etc/hosts
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Nov 16, 2007 5:47 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And if the QMGR is talking to external partners, use unique listeners for each partner (don't share). That way, you can turn just one off.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 16, 2007 6:08 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JosephGramig wrote: |
| And if the QMGR is talking to external partners, use unique listeners for each partner (don't share). That way, you can turn just one off. |
Unique listener by partner is a little bit extreme. We usually go by unique channel. You can always force shutdown a channel.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 16, 2007 6:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| JosephGramig wrote: |
| And if the QMGR is talking to external partners, use unique listeners for each partner (don't share). That way, you can turn just one off. |
Unique listener by partner is a little bit extreme. We usually go by unique channel. You can always force shutdown a channel. |
That doesn't work if they decide to start pinging your listener.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Nov 16, 2007 6:26 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Does too!
If the firewall rules don't allow the ping... Layers...
There's always more to it...
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 16, 2007 6:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| fjb_saper wrote: |
| JosephGramig wrote: |
| And if the QMGR is talking to external partners, use unique listeners for each partner (don't share). That way, you can turn just one off. |
Unique listener by partner is a little bit extreme. We usually go by unique channel. You can always force shutdown a channel. |
That doesn't work if they decide to start pinging your listener. |
You are really talking about a "denial of service" attack here and for that you need multiple listeners. However generally this is not linked to a particular partner so that you would need a listener per partner...
If you want to guard against that you'd probably need a netscaler or something of the kind and you can then redirect all partner traffic to the alternate listener port before it even hits the MQ server or filter out the server(s) used in the denial of service at the firewall... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 16, 2007 7:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| JosephGramig wrote: |
Does too!
If the firewall rules don't allow the ping... Layers...
There's always more to it... |
Yours does... FJ's doesn't.
And I'm not really talking about an "attack", per se. Just a parter that has an issue, and why it make not be as extreme as FJ says it is to isolate partner connections at the listener level.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Nov 16, 2007 7:08 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
It is extreme if the channels are not clustered. How would I stop a cluster receiver from talking to just one partner? And I would not put multiple partners in the same cluster (I'm not sure I would use a cluster with a partner at all) but I have seen this.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
|
|
