>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