MQ error code 2058 when connecting to queue manager by name

user_1636560 0
Viewed 11041

I'm experiencing an odd behavior when running basic connectivity tests from my workstation to a remote MQ Server.

I am using amqssslc.exe to connect from a command prompt.

If I connect with nothing but a certificate store, it connects without issue, and returns a result indicating that it connected to the default queue manager, FOO:

C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>amqssslc.exe -k c:\mycerts\cert

Sample AMQSSSLC start
Connecting to the default queue manager
No client connection information specified.
Using SSL key repository stem c:\mycerts\cert
No OCSP configuration specified.
Connection established to queue manager FOO
Sample AMQSSSLC end

If I attempt to connect to the queue manager FOO, however, it returns a 2058 error, which typically indicates a queue manager name error. 

C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>amqssslc.exe -k c:\mycerts\cert -m FOO

Sample AMQSSSLC start
Connecting to queue manager FOO
No client connection information specified.
Using SSL key repository stem c:\mycerts\cert
No OCSP configuration specified.
MQCONNX ended with reason code 2058

It does this even if I copy the name directly from the result. It fails quickly, and doesn't generate a log entry in my AMQERR01.LOG file.

Does this behavior indicate an issue with my CCDT file?

Update:

Per @JoshMc's suggestion, I ran the following command to get information about the vendor-supplied CCDT file:

echo DIS CHL(*) QMNAME CONNAME|runmqsc -n

The results indicated that no queue manager was specified in the file:

C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>echo DIS CHL(*) QMNAME CONNAME|runmqsc -n
5724-H72 (C) Copyright IBM Corp. 1994, 2016.
Starting local MQSC for 'MYQUEUE.TAB'.
 1 : DIS CHL(*) QMNAME CONNAME
AMQ8414: Display Channel details.
   CHANNEL(FOOCHANNEL)                CHLTYPE(CLNTCONN)
   CONNAME(CONNAME(xxx.xxx.xxx.xxx(1414),xxx.xxx.xxx.xxx(1414))
   QMNAME( )

No commands have a syntax error.
ibm-mq
2 Answers

If you review the source code located at C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64\amqssslc.c you can see that it does the following:

  1. If no queue manager name is specified it will set the queue manager name to NULL and print Connecting to the default queue manager
  2. If no connection name is specified it will not setup the ClientConn, and ConnectOptions.ClientConnPtr is left at it's default NULL value, it will print No client connection information specified.
  3. If a SSL key repository stem is specified it will set the SslConnOptions.KeyRepository to this value and print out Using SSL key repository stem <stem location> and then point ConnectOptions.SSLConfigPtr to the SslConnOptions.

After all of this it then issues a MQCONNX and specifies the the NULL queue manager name and the ConnectOptions. Because the ConnectOptions.ClientConnPtr is left at the default NULL value MQ will attempt to find the out how to connect to the queue manager via a few different other means. The order and where it looks for connection information is documented at the IBM v7.5 (or later) Knowledge Center page "Connecting IBM WebSphere MQ MQI client applications to queue managers". In your case it is picking up the CCDT file.

When you do not specify a queue manager name it looks for a entry in the CCDT with a blank QMNAME attribute and finds the CLNTCONN channel that you have defined where QMNAME is blank. A blank QMNAME on a CLNTCONN channel is a special case where the MQ client will connect to any queue manager name which is listening at CONNAME that you specify. Because you are specifying the SSL key repository stem it will use this key repository to connect to MQ with the SSLCIPH you have specified on CLNTCONN in the CCDT.

When you do specify the queue manager name FOO, it attempts to find a entry in the CCDT with the QMNAME attribute set to FOO, in your case it does not exist so you receive the 2058 or MQRC_Q_MGR_NAME_ERROR error.

Based on your update the CCDT channel does have a blank QMNAME attribute and the CONNAME lists two different IP(PORT) seperated by a common. With this configuration MQ will attempt first to connect to the first IP, if the connection times out or is ended for some other reason such as the channel on the queue manager being in STOPPED status, it will then attempt to connect to the second IP.

It is very possible they intend for you to connect with a blank or NULL queue manager name due to the benefit that the client will connect to any queue manager name that is listening on the CONNAME, in you case the first IP(PORT) might be queue manager FOO and the second IP(PORT) might be queue manager BAR.

If you want it to work with your CCDT when you specify -m FOO you would need to either create a new CCDT with a CLNTCONN channel with QMNAME(FOO), or add another CLNTCONN channel to your existing CCDT with QMNAME(FOO), note you can not have duplicate channel names in a single CCDT.

For more information on the CCDT and what queue manager name to specify see my answer to "Connecting to IBM MQ using CCDT file in JMS". The answer was related to JMS but the information applies to MQI clients as well.

You also have the option to specify all the details on the command line like Roger said. Run amqssslc.exe ? for usage information, it should look like this:

Sample AMQSSSLC start
Parameters:  [-m QMgr]
  [-c ChlName -x ConnName]
  [-k KeyReposStem] [-s CipherSpec]
  [-p any|rfc5280]
  [-f] [-b none|128_bit|192_bit[,...] ]
  [-o OcspURL]
user_72646200

I'm experiencing an odd behavior when running basic connectivity tests from my workstation to a remote MQ Server.

Its not the program. You didn't specify enough parameters. Did you issue "amqssslc.exe ?" or look at the source? i.e. amqssslc.c

Where is the channel name? Where is the connection name? Where is the CipherSpec? etc...

user_14317340
Related