B0Andrew February 2016

Connecting to Websphere MQ queue manager works in application A but not in application B

I have two console applications, A and B. The application A was created for test purposes and works as expected. The application B does not work although it is basically a copy-paste of A's code:

System.Console.Write("User Name: ");
string username = System.Console.ReadLine();
System.Console.Write("Password: ");
string password = ConsoleReadPassword();
System.Console.WriteLine();

//user and password required because I am also a privileged user 
//(member of mqm group)
MQEnvironment.UserId = username;
MQEnvironment.Password = password;

//for application B this line throws exception with code 2538
var queueManager = new MQQueueManager("TEST.QUEUE.MANAGER", "CLIENT.CONN.CHANNEL", "localhost(1414)");

Error code 2538 means "Host not available" which is weird because application A has no problems connecting to the same host.

This is how the MQ Server looks in MQ Explorer:

Queue managers: queue managers

Queues: queues

Listeners: listeners

Channels: channels Two server channels

Channel auth records: channel authentication records Default channel authentication record which pr

Answers


Morag Hughson February 2016

When using the hostname localhost networking is still involved, it just all happens inside the one machine. If application A is running in the same machine as your queue manager then having application A connect using the connection name localhost(1414) will certainly work but it is not necessary to make the connection like this (i.e. using TCP/IP) you could instead make a local bindings connection.

On the other hand, if you are using TCP/IP because application B is running on a different machine to where the queue manager is running, then using localhost(1414) will not work because localhost on one machine does not connect to localhost on another machine. You should change what is specified in the application's connection name from localhost(1414) to use the IP address (or hostname) of the queue manager's machine (followed as before with the port number).


B0Andrew February 2016

Although I was unable to find the cause of the problem the solution was to simply

delete and re-create the project.

This is what I tried before and what led me to this action:

  • In B I removed and then added back the reference to amqmdnet.dll - not working
  • I created yet another project (let's call it C): console application, same code - working
  • I renamed* the C project with the same name as B - still working

    *The name of the non-working project contained a dot so I thought that this could cause the problem - it was not the case.

Post Status

Asked in February 2016
Viewed 2,877 times
Voted 10
Answered 2 times

Search




Leave an answer