Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
3 replies Latest Post - ‏2012-07-26T16:38:21Z by fjb_saper
NealWalters
NealWalters
29 Posts
ACCEPTED ANSWER

Pinned topic C# API to MQ - Some QueueManagers connect, some don't

‏2012-07-20T16:21:35Z |
I have 5 queues on same server. Each already had a Receiver and Sender Channel. The only way I got one of them to connect was to create a server-connection channel, and use that as my channel name. Then I was able to communicate with that QueueManager. Now I want to do same with other QueueManagers. I created similar server-connection channel for the other queues, and I still get 2058 or 2009 or 2538 when trying to connect to them.

I'd like to confirm the following:
1) The Port to use can be found by looking at the TCP Port on the TCP properties of each queue manager. This is the port I use to connect, regardless of the send/receiver ports.
2) Do ChannelNames have to be unique across ports? I created one called QTServerChannel for the queue manager that works. Can I use the same name, "QTServerChannel" on the other queue managers, or does each one have to have a different name. I have tried both.
3) Is it possible or correct concept to "Start" a channel of channeltype='Server-Connection"? I see it "Running" when I'm running my C# program, but when I start it, it says "accepted", but keeps showing "Inactive" and never shows "Running".

Any other ideas of how to connect or what to check for? I can connet to only one out of my five queue managers.

Thanks,
Neal Walters
Updated on 2012-07-26T16:38:21Z at 2012-07-26T16:38:21Z by fjb_saper
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: C# API to MQ - Some QueueManagers connect, some don't

    ‏2012-07-20T19:41:46Z  in response to NealWalters
    Hi Neal,

    Welcome to the world of MQ !

    >I have 5 queues on same server.

    I think you mean 5 "queue managers". Queue managers contain many "local queues" and many other types of objects.

    >Each already had a Receiver and Sender Channel.

    OK, but these are of no use to client applications trying to connect to the qmgr. They are for linking qmgrs together in a point-to-point fashion.

    >The only way I got one of them to connect was to create a server-connection channel, and use that as my channel name.

    Great, you are now getting somewhere with a client connection!

    I assume each qmgr has a defined "listener" object that is running on a separate TCP port, eg 1414 1415 1416 1417 1418

    Its good practice to use a unique server connection channel name for each qmgr and each application. eg. MYAPP.QMGRNAME1 MYAPP.QMGRNAME1 Channel names can be up to 20 chars long.

    Each thread in your app can connect in client mode to one queue manager. The client needs to know 4 things to make a connection: channel name, host name (or IP address), port number, queue manager name. How you can specify these depends on the programming environment.

    While the client is connected, the qmgr should show a channel instance that is in RUNNING status.

    HTH, G.
    • NealWalters
      NealWalters
      29 Posts
      ACCEPTED ANSWER

      Re: C# API to MQ - Some QueueManagers connect, some don't

      ‏2012-07-24T14:19:47Z  in response to SystemAdmin
      Ahhh... the listener... Yes, and each one had a different TCP/IP port that I probably need to use.

      Pray tell, what is the different between that Port and the one when you Click then Queue-Manager, then Right-click "Properties", then look at "TCP".
      All of them had one the same port # in this property, but separate port #s in the listeners.

      Thanks!
      Neal Walters
      • fjb_saper
        fjb_saper
        169 Posts
        ACCEPTED ANSWER

        Re: C# API to MQ - Some QueueManagers connect, some don't

        ‏2012-07-26T16:38:21Z  in response to NealWalters
        The port you see in the properties is the default port that will be used if you do not specify a port when defining your channel. This is why the port should always be stated explicitly in the conname. No room for confusion...