| Author |
Message
|
| PeterPotkay |
 Posted: Wed Nov 24, 2004 9:22 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Looks like it is a problem on the remote side.
Now you have to prove there is a QM running on myservername, that it is listening on port 1885, and that is has a channel called S_channel.
On myservername, issue dspmq, and post the output.
Then issue a display channel command in runmqsc on that server, to show us that channel.
Any finally do a netstat -a for port 1885, to prove there is something listening on it. You could also try opening a telnet session from your client machine to myservername port 1885. That has to work if you expect your MQ Client to work.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bath |
| Posted: Wed Nov 24, 2004 10:57 am Post subject: |
|
|
Apprentice
Joined: 23 Nov 2004
Posts: 29
|
Once again Peter thank you,
please take a look to the output of the command i executed
a)dspmq
QMNAME(QM_a) STATUS(En cours d'ex‚cution)
QMNAME(QM_ws_roland) STATUS(En cours d'ex‚cution)
!!! PS: En cours d'ex‚cution =running
b)runmqsc
then i type display channel S_channel
the output:
websphere object MQ not found
i don't understand this because i can see my channel in the MQexplorer window.
c) netstat -a
output:
Connexions actives
Proto Adresse locale Adresse distante Etat
TCP ws_roland:epmap ws_roland:0 LISTENING
TCP ws_roland:microsoft-ds ws_roland:0 LISTENING
TCP ws_roland:MQSeries ws_roland:0 LISTENING
TCP ws_roland:1885 ws_roland:0 LISTENING
TCP ws_roland:1028 ws_roland:0 LISTENING
TCP ws_roland:1033 ws_roland:0 LISTENING
TCP ws_roland:3459 ws_roland:0 LISTENING
TCP ws_roland:netbios-ssn ws_roland:0 LISTENING
TCP ws_roland:1490 192.168.1.92:netbios-ssn ESTABLISHED
TCP ws_roland:3795 192.168.1.40:5000 ESTABLISHED
UDP ws_roland:microsoft-ds *:*
UDP ws_roland:isakmp *:*
UDP ws_roland:1037 *:*
UDP ws_roland:4500 *:*
UDP ws_roland:ntp *:*
UDP ws_roland:1518 *:*
UDP ws_roland:1900 *:*
UDP ws_roland:3395 *:*
UDP ws_roland:4831 *:*
UDP ws_roland:ntp *:*
UDP ws_roland:netbios-ns *:*
UDP ws_roland:netbios-dgm *:*
UDP ws_roland:1900 *:*
d) telnet test:
I type: telnet my_server_ip_adress 1885
output:
could not connect to the host on port 1885
thank you to answer me.
Roland |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 24, 2004 11:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Code: |
display channel('S_channel') all
|
will give you the channel info.
But if you can't telnet into port 1885, and 1885 is in fact being listened on by something, then this is not an MQ issue but some sort of network / firewall issue that is preventing your machine from talking to that machine on that port.
Get the telnet to port 1885 working first, then worry about MQ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bath |
| Posted: Wed Nov 24, 2004 11:50 am Post subject: |
|
|
Apprentice
Joined: 23 Nov 2004
Posts: 29
|
I will first solve my network problem
Many thanks
Roland |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 24, 2004 4:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
And make sure that you do not need to switch the port to something else.
netstat -an clearly shows that 1885 is listening on something. Now this may or maynot be the MQ listener that is listening on the port. Make sure it is not a different process.
I suggest that you check with the system admin for available ports and assign an available port to the qmgr.
If after that you still can't access the port it is definitely a firewall / network / tcp issue that needs to be resolved first.
Enjoy |
|
| Back to top |
|
|
| lim |
| Posted: Tue Dec 07, 2004 2:42 pm Post subject: same problem |
|
|
Newbie
Joined: 07 Dec 2004
Posts: 2
Location: Belgium
|
Hi,
I encountered the same problem on a Windows XP prof machine, MQ 5.3, upgraded to CSD8.
Tried to connect locally on this PC 'pclim', to the default queue manager QM_pclim.
I set MQSERVER=S_pclim/TCP/localhost
After some failures with pymqi (python) I reduced it to the simplest C program:
| Code: |
#include <stdio.h>
#include "cmqc.h"
int main(int argc, char* argv[])
{
char *name="QM_pclim";
MQHCONN handle;
MQLONG compCode, compReason;
MQCONN(name, &handle, &compCode, &compReason);
printf("handle %p - compcode %d - compreason %d \n",handle,compCode,compReason);
return 0;
}
|
which outputs:
| Code: |
C:\lim\mqtest\Debug>mqtest
handle CCCCCCCC - compcode 2 - compreason 2059
C:\lim\mqtest\Debug>
|
In the Windows event logs I find an error event from application Websphere MQ:
| Quote: |
Error on receive from host localhost (127.0.0.1).
An error occurred receiving data from localhost (127.0.0.1) over TCP/IP. This may be due to a communications failure.
The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator.
|
and a subsequent
| Quote: |
A communications error for TCP/IP occurred.
An unexpected error occurred in communications.
The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736'). Record these values and tell the systems administrator.
|
I also tried to set MQSERVER=S_pclim/TCP/pclim. Same result.
Any ideas ?
_________________
--
Lieven Matthys
IBM Global Services |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Dec 07, 2004 3:37 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| The return code from the TCP/IP (recv) call was 10054 (X'2746'). |
That's usually a networking problem. But I wouldn't expect it on localhost.
| Quote: |
| The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736'). |
That "could" be the MQNOREMPOOl problem. Try setting an environment variable MQNOREMPOOL=1, reboot, and retry.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| lim |
| Posted: Wed Dec 08, 2004 8:30 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2004
Posts: 2
Location: Belgium
|
Thanks for the reply,
in the meantime I also found out that it was indeed the "MQNOREMPOOL" problem.
The 10054 error remained and is simply due to the client program exiting without closing the queuemanager connection. Of course, with the MQNOREMPOOL problem the connection can't be closed, since you never get a proper handle.
FYI:
Apparently the problem is related to the unability of Windows to pass an open socket between processes in some circumstances. Setting MQNOREMPOOL keeps the socket in the listener process, the handler for the socket is a thread.
In my particular case I suspect the presence of the Aventail transparent socksifier software (within IBM aka IBM SINE client). This software is known to break sockets based programs in several ways (e.g. cygwin's sshd) even if it is not active.
kind regards,
Lieven
_________________
--
Lieven Matthys
IBM Global Services |
|
| Back to top |
|
|
|
|
