Tips for troubleshooting

An XMS application cannot connect to a queue manager (MQRC_NOT_AUTHORIZED)

The XMS .NET client may have different behavior from the behavior of the IBM® WebSphere® MQ JMS client. Therefore, you may find that your XMS application cannot connect to your queue manager, although your JMS application can.

• A simple solution to this problem is to try using a user ID that is no more than 12 characters long and is authorized completely in the queue manager's authority list. If this solution is not ideal, a different but more complex approach would be to use security exits. If you need further help on this issue, contact IBM Support for assistance.
• If you set the XMSC_USERID property of the connection factory, it must match the user ID and password of the logged on user. If you do not set this property, the queue manager uses the user ID of the logged on user by default.
• User authentication for IBM WebSphere MQ is performed by using the details of the user currently logged on and not the information provided in the XMSC.USERID and XMSC.PASSWORD fields. This is designed to maintain consistency with IBM WebSphere MQ. For more information on authentication, refer to Authentication Information in the online IBM IBM WebSphere MQ product documentation.

Connection redirected to the messaging engine

When you connect to a WebSphere Application Server Version 6.0.2 service integration bus, all connections may be redirected from the original provider endpoint to the messaging engine that the bus chooses for that client connection. When doing so, it will always redirect the connection to a host server specified by the hostname, rather than by an IP address. Therefore, you may experience connection problems if the hostname cannot be resolved.

To successfully connect to WebSphere Application Server Version 6.0.2 service integration bus, you may need to provide a mapping between the hostnames and IP addresses on your client host machine. For example you can specify the mapping in a local hosts table on your client host machine.

An XMS application using a larger JVM heap

The XMS .NET application that sends messages through the WebSphere Application Server messaging engines typically needs to use a larger JVM heap than the default specified. To change heap configuration settings, refer to Tuning messaging performance with service integration technologies in the WebSphere Application Server Version 7 product documentation.

Support for telnet-like password authentication

The XMS .NET Real Time Transport protocol supports only simple telnet-like password authentication. The XMS .NET Real Time Transport protocol does not support Quality Of Protection.

Setting values for property type double

On a Windows 64-bit platform, the SetDoubleProperty() or GetDoubleProperty() methods may not work correctly when setting or getting values for the property type double, if the values are smaller than Double.Epsilon.

For example, if you try to set a value of 4.9E-324 for a property with type double, the Windows 64-bit platforms treat it as 0.0. So, in a distributed messaging environment, if a JMS or another application sets the value for a double property as 4.9E-324 on any Unix or Windows 32-bit machine, and XMS .Net runs on a 64-bit machine, the value returned by GetDoubleProperty() is 0.0. This is a known issue with Microsoft .NET 2.0 Framework.