| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Sender Channel probelm |
« View previous topic :: View next topic » |
| Author |
Message
|
| BFREI |
 Posted: Thu Nov 01, 2001 8:30 am Post subject: |
 |
|
Newbie
Joined: 29 Oct 2001
Posts: 5
Location: Canada
|
Hi ,we are running MQ V1.2 on OS/390 V2.8 using TCPIP. We have nemerous sender channels set up to connect with a unix box. These channels have been running fine until last weekend. The reciever channels on the unix box went into retry and our sender channels on the mainframe got an error, 'unable to connect to remote Q Managaer' ? After trying a lot of different things, we hardcoded the port (1414) in the CONNAME attribute of the sender channel defenition. The channel came up and all was good? We then hardcoded the rest of our sender channels and we are now running fine? My question is this: Why do we have to hardcode our mainframe sender channels to include port (1414) along with the IP address? I always thought that port 1414 was the default for MQ? These channels have been running fine for a long time. This past weekend, something must have changed to have MQ need the 1414 hardcoded? Any ideas where I can look to see why we now need to hardcode a the default port of (1414).I'm suspecting something changed with TCPIP or the network, but not really sure?
Thanks.....
_________________
Regards,
Bob
[ This Message was edited by: BFREI on 2001-11-02 07:20 ] |
|
| Back to top |
|
 |
| bduncan |
| Posted: Thu Nov 01, 2001 11:02 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Bob,
You should never have to put the port number in the CONNAME attribute (assuming that the port is 1414). I would claim that there must have been something else wrong to cause the symptoms you saw. I'm curious, when you altered the channels to add the port number, did you do anything else before you saw them running again? In other words did you issue any STARTs, STOPs, RESETs, PINGs, etc? Perhaps it was issuing one of these commands that caused the queue manager to resolve the channel, ignoring the fact that you entered the port number...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| BFREI |
| Posted: Thu Nov 01, 2001 11:42 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2001
Posts: 5
Location: Canada
|
Hi Barndon, it does seem rather bizarre, but we did try numerous stops and starts, even tried ping, but got the message " remote listener unavailable'? It was just when we hardcoded the port that the channel would start? We are setting up a couple test channels to see if we can duplicate the problem. Anything else we could look at?
_________________
Regards,
Bob |
|
| Back to top |
|
|
| BFREI |
| Posted: Thu Nov 01, 2001 12:25 pm Post subject: |
|
|
Newbie
Joined: 29 Oct 2001
Posts: 5
Location: Canada
|
UPDATE
We configured test channels and can reproduce the problem. If we include the port (1414) in the conname along with the ip , we can connect to the q manager on the unix box. When we take the port number out , we get the error 'remote listener unavailable'? This tells me that either MQ is defaulting the wrong port (something other than 1414) or there may be an issue with the network or possible firewall on the midrange side. The midrange network people assure me there has been no changes? I am having hard time seeing how MQ would default a port other than 1414, and my knowledge of firewalls and midrange network is limited, so if anyone has any idea's please respond.
Bob
_________________
Regards,
Bob |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Nov 01, 2001 5:55 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Bob,
In your first post, you had said that everything was running fine until recently. Did this coincide with some unusual event? I ask, because in your most recent post you say you can replicate the problem. So is there anything you need to do to "create" the problem, or do you simply set up the queue manager, and experience it?
As far as defaulting to some other port, this is possible. You should be able to see what it is set at by looking at the qm.ini file for your queue manager (found in /var/mqm/qmgrs/qmgrname). Somewhere you should see the following:
TCP: ; TCP/IP entries
Port = 1800 ; use port 1800 instead of the default 1414
KeepAlive = Yes ; Switch KeepAlive on
So in this example, all sender channels should default to 1800 rather than 1414. And if your receiving queue manager is listening on 1414, then the only way to get the sender channels to successfully connect would be to hardcode 1414 in the conname.
As an aside, there is no way to specify default port during the crtmqm command as you would expect. So this means that the only way this value can be changed (assuming that it is indeed something other than 1414 in your case) is for someone to go in and alter the qm.ini file and then restart the queue manager.
If this isn't your problem, let me know, because I might have a few other ideas...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| BFREI |
| Posted: Fri Nov 02, 2001 6:38 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2001
Posts: 5
Location: Canada
|
Hi Brandon, sounds logical, but our problem is on the OS/390 side. We set up a test sender and reciever on the mainframe going to the unix box. If we don't hardcode 1414 in the conname on the mainframe side, we can't connect to unix. When we hardcode 1414 on the mainframe side, we can connect? This just started happening after an IPL over the weekend? These channels have been running fine for 2 years? No changes have been made to MQ. This is why I am thinking something changed in the network or firewall of the unix end? Again, my knowledge of firewalls and network on the midrange side is limited, so I have to take the network support people's word that nothing has changed? I know we should not have to hardcode 1414 on the sender channel on mainframe, but for whatever reason, this seems to be a temporary work around?
_________________
Regards,
Bob |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Nov 02, 2001 11:40 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
hahaha.. I don't know how many times I've had to deal with network people who say "nothing's changed" when MQSeries suddenly starts having problems... Invariably, it turns out that something DID change. Sometimes they really didn't know about the change - a tech tripping over the power cord for a hub, someone making a change to a config file months before that didn't take effect until the box got rebooted - long after they forgot about the change, etc... Perhaps you should try starting the channel without the port number hardcoded, and then on the receiving side, run a port sniffer. This way you can detect what port the sender channel is actually trying to connect to, because it doesn't appear to be 1414... Good luck...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| BFREI |
| Posted: Fri Nov 16, 2001 2:27 pm Post subject: |
|
|
Newbie
Joined: 29 Oct 2001
Posts: 5
Location: Canada
|
Hi Brandon , turns out there was a change made to the linklist, and an old TCP/IP services file was made available to MQSeries. This file contained an old MQSeries entry that pointed to a port other than (1414)thus causing MQ to use this port not the default. It has been fixed up and all is back to normal. Thanks..........
_________________
Regards,
Bob |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Nov 16, 2001 3:15 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Glad to know you got the problem resolved. I actually should have mentioned that possibility because it's happened to me in the past. Our production team did automatic OS builds to upgrade our systems quickly, and one time the /etc/inetd.conf file in the build scripts got changed, and it screwed up our systems everytime they did a build... Took a while to figure out why the inetd.conf files kept changing...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| 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
|
|
|
|
