| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Sender channel failing |
« View previous topic :: View next topic » |
| Author |
Message
|
| merlin |
 Posted: Fri Feb 25, 2005 7:52 am Post subject: Sender channel failing |
 |
|
Novice
Joined: 07 Mar 2004
Posts: 19
|
Bit of an odd one, and I have to admit I don't know if this falls into the Clustering section of the forum... so forgive me if this should be on a more general section! 
Client has very simple MQ cluster (at present) consisting of Queue Manager on iSeries and another QM on Windows (at different location). Have had this set up working just fine, with both managers set to be Repository managers, both hosting queues that the other one can see just fine.
Suddenly, the sender channel stopped working on the Windows server, so messages unable to get to the iSeries MQ. Thought perhaps this might be a service pack issue (as both installation were only level 1) and as the upgrade was scheduled with the client, told them I thought the upgrade would sort it.
I was wrong! Even after the upgrade (went ok on both boxes) the sender channel would not work. Did some searching on internet to try and identify what the problem was , here is a copy of the error message I was seeing in the qmgr error log:
--------------------------------------------------------------------------------
02/23/2005 14:35:37
AMQ9203: A configuration error for TCP/IP occurred.
EXPLANATION:
Error in configuration for communications to host ''. Allocation of a TCP/IP
conversation to host '' was not possible.
ACTION:
The configuration error may be one of the following:
1.If the communications protocol is LU 6.2, it may be that one of the
transmission parameters (Mode, or TP Name) is incorrect. Correct the error
and try again. The mode name should be the same as the mode defined on host
''. The TP name on '' should be defined.
2.If the communications protocol is LU 6.2, it may be that an LU 6.2 session
has not been established. Contact your systems administrator.
3.If the communications protocol is TCP/IP, it may be that the host name
specified is incorrect. Correct the error and try again.
4.If the communications protocol is TCP/IP, it may be that the host name
specified cannot be resolved to a network address. The host name may not be
in the nameserver.
The return code from the TCP/IP (connect) call was 10049 (X'2741').
Record the error values and tell the system administrator.
-----------------------------------------------------------------------
ok, i managed to fix this - all i ultimately did was to put the hostname into the definition of the cluster receiver channel over on the iSeries! I haven't needed to tell the cluster receivers (either on iSeries or Windows) before now what hostname they were running on, they have always self-resolved. I always thought it only mattered that you had a value in the conname for the cluster SENDER channel definition.
Guess not...
Now, does anyone out there understand WHY I got this problem? Why should this suddenly go wrong, when as far as I can determine, no-one had been pratting about with either MQ or the machines in question.
And how about that bit in the MQ error above, where the Windows SENDER channel is failing cos it doesn't know where to connect to - even though the def for the sender of course has the conname correctly set...
Somebody, please, put me out of my misery...  |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Fri Feb 25, 2005 8:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| The definition of a CLUSSDR, even a manual one used to communicate with another full repos, is copied from the corresponding CLUSRCVR with the same name. This meant that the blank CONNAME from the iSeries was copied to the Windows box. This is documented in the Clusters manual, CH 4, Components of a cluster, Auto-definition of channels. |
|
| Back to top |
|
|
| merlin |
| Posted: Fri Feb 25, 2005 8:35 am Post subject: |
|
|
Novice
Joined: 07 Mar 2004
Posts: 19
|
thanks Nigel,
can you perhaps explain how come I didn't need a conname value before in the cluster receivers? That's the part I find odd, that it can be inconsistent.
Or is simply that, normally, the MQ where you create the receiver fills in the blank conname with the appropriate one it works out from the machine its running on? And that then gets passed into the corresponding Sender. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 25, 2005 9:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| merlin wrote: |
can you perhaps explain how come I didn't need a conname value before in the cluster receivers? That's the part I find odd, that it can be inconsistent.
Or is simply that, normally, the MQ where you create the receiver fills in the blank conname with the appropriate one it works out from the machine its running on? And that then gets passed into the corresponding Sender. |
A cluster with blanks for the connames in the CLUSRCVRS was never really a cluster. The only time the Manually defined CLUSSNDR channel (with the destination conname coded) is ever used is the very first time the QM calls to the Full Repository (or if you issue the REFRESH command with the REPOS(YES) option). All other times, the sending QM will create automatic cluster sender channels to every other QM in the cluster, even the FR you just created a manual channel to, based on the CLUSRCVR channel def of the destination QM.
If that CLUSRCVR had a blank conname, you were not using clustering.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| merlin |
| Posted: Sat Feb 26, 2005 12:46 am Post subject: |
|
|
Novice
Joined: 07 Mar 2004
Posts: 19
|
Thanks guys for the explanation... 
at least I've learned something in all this. |
|
| 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
|
|
|
|
