>I am trying to create a pair of channels between a Win 2k machine and a
>Win XP machine. On the Win XP machine I can do a ping channel to the
>Win2k machine. When I try the same thing on the Win 2k machine I get an
>error and  in the general error log on the Win XP machine I get:

>AMQ9213: A communications error for TCP/IP occurred.

>EXPLANATION:
>An unexpected error occurred in communications.
>ACTION:
>The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736').
>Record
>these values and tell the systems administrator.

>I looked up what a 10038 and it is a WSAENOTSOCK -- Socket operation on
>non-socket.
>The userid that I am logged on with is in the mq user group. I am
>running MQ v5.3 CSD4.
>I am running Win XP professional and have enable all the possible
>permission available to NETWORK and ANONYMOUS users. I suspect it maybe
>a permission problem but I haven't found any more information to confirm
>this. The network is ethernet lan using a workgroup rather than a domain.
>Any ideas?

Donald,

A number of people have had similar problems and if you do a few searches
on the Web you'll find a number of possible causes and solutions. This is
in many cases a Microsoft bug ; look at MS Knowledge base article Q319952.
This concerns passing sockets between processes if you're listening on the
localhost, using the loopback adaptor or the network cable is unplugged.
There have been other suspicions that low level products such as firewalls
could be getting in the way.

Let me explain what is happening. In 5.3 of WMQ we have a feature called
channel pooling. What this means is that an inbound channel connecting to a
listener is not run as a thread of the listener process as before but is
instead passed to one of a pool of processes (AMQRMPPA). This works great
(most of the time) and allows a single listener to handle many thousands of
connections. Unfortunately, depending on your exact machine set up (windows
version, firewalls, network addresses etc) sometimes the socket is no
longer valid when it arrives in the other process.

A workaround solution is to tell MQ to run the old way. In other words run
the inbound channels in the listener process itself. You can do this by
ensuring the environment variable MQNOREMPOOL is set (to anything you like)
before you start the listener. Clearly this is not ideal since you will not
be as scalable as with channel pool switched on but if you have less than a
thousand connected channels you should have no problems.

Cheers,
P.

Paul G Clarke
WebSphere MQ Development
IBM Hursley

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to