Find Port Number of Ibm Mq Queue Manager

find port number of IBM MQ Queue Manager

Use netstat as root with -p option

sudo netstat -nltp
[sudo] password for root: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1362/dnsmasq        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1580/sshd           
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1480/cupsd

The last column gives the PID and 'Program name'. If you are running the queue manager with your user, you don't need to sudo.

How to find MQ listener port on AIX?

You will need to create a listener after starting the queue manager. The crtmqm command creates default listener for all the supported transport types. It is recommended you create your own listener. Do the following in a MQSC shell

DEF LISTENER(MYMQLISTENER)  TRPTYPE(TCP) +
    CONTROL(QMGR)            PORT(1414) +
    REPLACE

START LISTENER(MYMQLISTENER)

The above command creates a listener with a name MYMQLISTENER transport and the listens on port 1414. The CONTROL(QMGR) directs the queue manager to start the listener when queue manager starts and stop it when queue manager goes down. The START LISTENER command starts the listener. You also have STOP LISTENER MQSC command to stop the listener.

Once you create and start the listener, you can then issue DISPLAY LSSTATUS command to display the listener status.

Are there more than one queue manager allowed per host/port?

There's a lot to unwind in this question so let's take it one item at a time.

There can be only one listener bound to a particular port and interface. So if the listener is promiscuous (listens on all interfaces) there's only one per port. If the host has multiple interfaces separate listeners can be bound on the same port on each of the interfaces. Since a listener is a child process of the queue manager, the implication is only one QMgr can listen on a given address(port) combination.

The QMgr name need not be present in the connection request received by the QMgr. If the QMgr name is blank, the connection succeeds with any QMgr to which the connection request is addressed, provided that QMgr does not reject it for bad password, certificate validation or other errors. However, if a QMgr name is in the connection request it must match the name of the QMgr to which the connection is attempted.

Connection Namelist (more properly CONNAME)is a comma-separated list of address(port) combinations that are eligible to receive the connection being requested.

Multi-Instance QMgrs have two addresses and one port. They are only ever active on one address and a channel pointing to them must have both addresses to be able to connect reliably. However, it need not have the QMgr name.

But there is another type of HA in which there are multiple equivalent QMgrs, each with different names, to which a client can connect. This is especially true when the client is requesting information from a system of record but is not itself a system of record. Such a client has no need to listen on a well known queue. Instead it connects to any one of a tier of client-connection QMgrs, creates a dynamic Reply-To queue, and sends requests out to the system of record listening on a clustered queue out in the MQ network somewhere. In this scenario, the client doesn't specify a QMgr name and thus takes advantage of MQ's behavior of accepting whatever QMgr it connects to.

Finally, MQ has long had Client Channel Definition Table or CCDT files. Before we had multi-instance CONNAME the CCDT provided the capability of connecting to any of several QMgrs. Rather than putting a QMgr name in the CCDT the MQ Admin put symbolic names. For example if there were 3 QMgrs for Payroll processing, the QMgr names in their CCDT entries might be PAY01, PAY02, and PAY03, none of which match the actual QMgr names. Each of these has an address(port) pointing to one of the three QMgrs. The developer then specifies a QMgr name of *PAY and the MQ client would pick among all CCDT entries with the first 3 characters matching 'PAY'. With this and a few other options it was possible to have the MQ client drive reconnects but have the MQ client stub encapsulate the logic of whether to round-robin among destinations, retry the last connected address, or whatever.

From this pattern it seems that the queue manager name is necessary to
fully identify the queue manager. One might concluded that on the same
host and port a different queue manager might listen. Is this
possible?

No.

We have two queue managers listening on different hosts/ports which
have different names. We want to use one of these queue managers as
failover manager in the connection name list. The question is: is the
queue manager uniquely identified by host and port only?

Make sure the QMgr name is blank on the request and specify both address(port) combinations in the CONNAME and you should be good to go.

Please see: Role of the client channel definition table, and in particular in that section Queue manager groups in the CCDT. The section on Examples of channel weighting and affinity is also helpful here.

Finally, be sure that you are using a modern client. Since MQ clients can connect to any forward- or back-level QMgr it is possible to develop on a v9.0 client and connect to a v7.1 QMgr. Of course the functionality provided is based on the lowest version of client or QMgr so you don't get JMS 1.2 features with a v9.0 client and an ancient QMgr. However, you do get all the performance improvements and bug fixes in the later client versions. If you are not at the latest client (or the latest one supported by your JEE server) then go download one at:

• SupportPac MQC75
• SupportPac MQC8
• SupportPac MQC9

How to specify a queue manager when using PCFMessageAgent(host, port, channel) constructor?

No need to specify queue manager, as soon as you specify host and port.
You will connect to the one listening to that port.

Update, from IBM docs:

A server connection channel is a bidirectional MQI channel that is
used to connect a IBM WebSphere MQ client to a IBM WebSphere MQ
server. The server connection channel is the server end of the
channel.

A client connection channel is a bidirectional MQI channel that is
used to connect a IBM WebSphere MQ client to a IBM WebSphere MQ
server. IBM WebSphere MQ Explorer also uses client connections to
connect to remote queue managers. The client connection channel is
the client end of the channel. When you create a client-connection
channel, a file is created on the computer that hosts the queue
manager. You must then, copy the client-connection file to the IBM
WebSphere MQ Client computer.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.explorer.doc/e_channels.htm

---

Related Topics