Ibm mq error 2058

Troubleshooting

If you review the source code located at C:Program FilesIBMMQToolscSamplesBin64amqssslc.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]

9.3.6. Добавление тестовых сообщений в очередь

Ниже рассказывается, как поместить в ранее созданную очередь сообщения с произвольным текстом при помощи WebSphere MQ Explorer и программы-примера amqsput для WebSphere MQ, работающей с менеджером очередей по умолчанию на данном компьютере.

Видно, что после добавления сообщений в очередь значение ее атрибута «текущая длина» ( CURDEPTH ) изменяется и отражает число добавленных сообщений. О просмотре этого атрибута см. в
«Обмен сообщениями с использованием WebSphere MQ: практическое введение»
.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Выделите папку Queues менеджера очередей host1/qm1, расположенную в папке Queue Managers в окне навигатора.
2. Щелкните правой кнопкой строку queue1 в таблице и выберите команду Put Test Message – откроется одноименное окно.
3. Введите в поле Message data текст сообщения.
4. Щелкните Put message – поле Message data опустеет. Так можно ввести несколько тестовых сообщений; после ввода каждого сообщения щелкайте Put message.
5. Щелкните Close, чтобы закрыть окно.

Применение программы-примера для WebSphere MQ

Примечание Путь к каталогу с примерами программ для WebSphere MQ должен быть добавлен к пути поиска в переменных окружения ОС.

Выполните следующие действия.

1. Выполните следующую команду:

   Генерируется следующий вывод, после чего команда ожидает ввода пользователя:

   Sample AMQSPUT0 start
   target queue is queue1

2. Введите сообщение и нажмите клавишу Enter. Так можно ввести несколько тестовых сообщений; после ввода каждого сообщения нажимайте Enter.
3. Чтобы выйти, нажмите Enter, не вводя текста.

Sample AMQSPUT0 start
MQCONN ended with reason code 2059

Sample AMQSPUT0 start
target queue is QUEUE1
MQOPEN ended with reason code 2085
unable to open queue for output
Sample AMQSPUT0 end

2058 0x0000080a MQRC_Q_MGR_NAME_ERROR
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME

9.3.7. Просмотр сообщений, добавленных в очередь

Здесь рассказывается, как осуществляется просмотр сообщений, находящихся в данный момент в очереди WebSphere MQ, без их удаления. Для просмотра доступно как содержимое сообщений, так и сведения о них, хранимые в дескрипторах сообщений.

Сообщения, добавляемые в очередь, являются непостоянными ( nonpersistent messages ). В поле reply-to queue manager сообщений автоматически записывается строка host1/qm1 менеджером, в чью очередь добавлены эти сообщения.

Сообщения, генерация которых описана в
«Обмен сообщениями с использованием WebSphere MQ: практическое введение»
, представляли собой дейтаграммы, то есть сообщения, не требующие ответа.

В силу этой причины значение reply-to queue не определялось WebSphere MQ Explorer или программой-примером amqsput при добавлении сообщения.

Сейчас мы воспользуемся интерфейсом WebSphere MQ Explorer либо программой-примером amqsbcg для WebSphere MQ.

Примечание Эти методы весьма удобны при разработке, тестировании и мониторинге очередей рабочих систем, поскольку такой метод просмотра никак не влияет на содержащиеся в очереди сообщения.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой очередь в таблице менеджера очередей и выберите Browse Messages – откроется окно с индикатором хода операции, а затем окно Message browser.
2. Каждая строка в таблице, отображаемой в окне Message browser, представляет одно из сообщений в очереди. В столбцах этой таблицы отображается информация о сообщении, которая находится в дескрипторе сообщения, а также содержимое или данные сообщения. Настраивая схему таблицы, можно изменять порядок столбцов, чтобы, например, переместить столбцы Persistence, Message type, Message data, Reply-to queue и Reply-to Queue Manager в начало таблицы.
3. Некоторые типы сообщений лучше просматривать в виде двоичных данных, а не текста. Для этого дважды щелкните строку таблицы, представляющую сообщение, – откроется окно свойств сообщения. Щелкните секцию Data в этом окне.

Применение программы-примера для WebSphere MQ

Выполните следующие действия:

1. Выполните следующую команду для просмотра сообщений в очереди менеджера по умолчанию; вывод команды будет перенаправлен в файл queue1.txt:

   amqsbcg queue1 > queue1.txt

2. Откройте queue1.txt в любом текстовом редакторе. Для каждого из сообщений в файле содержатся сведения из дескриптора и содержимое в двоичном и текстовом (справа) представлении.

Читать сведения из такого файла сложнее, чем в WebSphere MQ Explorer. Разберем значение наиболее интересных полей вывода команды amqsbcg.

Тип 8 соответствует дейтаграммам. Запросы имеют тип 1, ответы – 2, отчеты – 4.

Значение «0» свидетельствует о том, что сообщение является непостоянным, а значение «1», напротив, говорит о том, что это сообщение является постоянным.

В этом поле отображается 48-значное имя очереди ответов (reply-to queue). Если в имени меньше 48 символов, недостающие символы заменяются пробелами, расположенными справа. Такие данные называются дополненными пробелами (blankpadded), они часто используются в структурах WebSphere MQ. В этом примере данное поле в дескрипторе сообщений пусто.

ReplyToQMgr : 'host1/qm1 '

Это поле содержит 48-значное дополненное пробелами имя менеджера очереди ответов (reply-to queue manager), оно автоматически заполняется менеджером очередей при размещении сообщения.

**** Message ****
length – 20 bytes
00000000: 5265 6462 6F6F 6B20 7465 7374 206D 6573   'Redbook test mes'
00000010: 7361 6765                     'sage '

Здесь отображается содержимое сообщения в двоичном и (справа) в текстовом представлении. Это существенно облегчает просмотр содержимого некоторых типов сообщений, особенно объемных, которые проще просматривать в двоичном представлении. Впрочем, содержимое простых тестовых сообщений из наших примеров как раз удобнее просматривать в текстовом представлении.

3 ответа

Problem statement: Websphere MQ error 2058 ASN0575E while issuing the WebSphere MQ command «MQCONN» on object «*»

Solution: The above error is very common error for most of the users when a Queue manager tries to access a queue or when it tries to issue MQCONN call on the queues which are not belonging to it then it gives us an error.

ASNCLP SESSION SET TO Q REPLICATION;
CREATE MQ SCRIPT CONFIG TYPE B
MQSERVER 1 NAME TESTA MQHOST «fedorabox» MQPORT 2416 QMANAGER QMTA QNAME_QUAL ASNTA, 
MQSERVER 2 NAME TESTB MQHOST «fedorabox» MQPORT 2417 QMANAGER QMTB QNAME_QUAL ASNTB;
=======================================================================
In the above setup following are the configurations.

Database 1 : TESTA
Database 2 : TESTB
QManager name for TESTA database is: QMTA
QManager name for TESTB database is: QMTB
Schema that we are using for TESTA database is ASNTA under which control tables, replication queue maps and all replication related objects are created in this schema.
Schema that we are using for TESTB database is ASNTB under which control tables, replication queue maps and all replication related objects are created in this schema.

========================================================================
ASNCLP SESSION SET TO Q REPLICATION;
SET OUTPUT MULTIDIR;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET BIDI NODE 1 SERVER DBALIAS TESTA ID «DB2INST1» PASSWORD «db2inst1» SCHEMA ASNTA;
SET BIDI NODE 2 SERVER DBALIAS TESTB ID «DB2INST1» PASSWORD «db2inst1» SCHEMA ASNTB;
CREATE CONTROL TABLES FOR NODE 1;
CREATE CONTROL TABLES FOR NODE 2;
CREATE REPLQMAP «TESTA.ASNTA_TO_TESTB.ASNTB» (NODE 1, NODE 2);
CREATE REPLQMAP «TESTB.ASNTB_TO_TESTA.ASNTA» (NODE 2, NODE 1);

Above script defines control tables for NODE1 and NODE2 and replication queue maps for NODE1 and NODE2
========================================================================

1) When i run the first set of commands using asnclp it will give scripts for BIDIRECTIONAL replication between two databases TESTA and TESTB and setup Queue managers QMTA for TESTA, QMTB for TESTB and sets replication schema ASNTA for TESTA and ASNTB for TESTB

2) When i run the second set of commands using asnclp it will give script for setting up control tables and replication queue maps between both the database viceversa

Everything ran successfully Queue managers QMTA and QMTB are up and running and all necessary objects are created. But when i start the Q capture program and when it tries to issue MQCONN call it wasnt able to identify the queues and gave me MQ error 2058, because in the above script i didnt specify queue manager name for NODE1 and NODE2.

SET QMANAGER QMTA FOR NODE 1;
SET QMANAGER QMTB FOR NODE 2;

When i added above two lines to second script that is setting the which qmanager to which node, then all the objects are created with the right Queue managers. Before running this script again i have dropped the schema ASNTA and ASNTB from both sides.

ASNCLP SESSION SET TO Q REPLICATION;
SET OUTPUT MULTIDIR;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET BIDI NODE 1 SERVER DBALIAS TESTA ID «DB2INST1» PASSWORD «db2inst1» SCHEMA ASNTA;
SET BIDI NODE 2 SERVER DBALIAS TESTB ID «DB2INST1» PASSWORD «db2inst1» SCHEMA ASNTB;
SET QMANAGER QMTA FOR NODE 1;
SET QMANAGER QMTB FOR NODE 2;
CREATE CONTROL TABLES FOR NODE 1;
CREATE CONTROL TABLES FOR NODE 2;
CREATE REPLQMAP «TESTA.ASNTA_TO_TESTB.ASNTB» (NODE 1, NODE 2);
CREATE REPLQMAP «TESTB.ASNTB_TO_TESTA.ASNTA» (NODE 2, NODE 1);

Then i was able to start the capture program and apply program and was able to successfully start the replication. Below link has helped me diagnosing the error
http://www-01.ibm.com/support/docview.wss?uid=swg21166938

Простой способ исправить код ошибки 0X80070005

Я испытываю странное поведение при запуске базовых тестов подключения с моей рабочей станции на удаленный сервер MQ.

Я использую amqssslc.exe для подключения из командной строки.

Если я подключаюсь только к хранилищу сертификатов, он подключается без проблем и возвращает результат, указывающий, что он подключен к диспетчеру очередей по умолчанию, FOO:

C:Program FilesIBMMQToolscSamplesBin64>amqssslc.exe -k c:mycertscert Sample AMQSSSLC start Connecting to the default queue manager No client connection information specified. Using SSL key repository stem c:mycertscert No OCSP configuration specified. Connection established to queue manager FOO Sample AMQSSSLC end 

Однако если я попытаюсь подключиться к диспетчеру очередей FOO, он вернет ошибку 2058, которая обычно указывает на ошибку имени диспетчера очередей.

C:Program FilesIBMMQToolscSamplesBin64>amqssslc.exe -k c:mycertscert -m FOO Sample AMQSSSLC start Connecting to queue manager FOO No client connection information specified. Using SSL key repository stem c:mycertscert No OCSP configuration specified. MQCONNX ended with reason code 2058 

Это происходит, даже если я копирую имя прямо из результата. Он быстро выходит из строя и не создает запись журнала в моем файле AMQERR01.LOG.

Указывает ли такое поведение на проблему с моим файлом CCDT?

Обновить:

По предложению @JoshMc я выполнил следующую команду, чтобы получить информацию о файле CCDT, предоставленном поставщиком:

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

Результаты показали, что в файле не указан администратор очередей:

C:Program FilesIBMMQToolscSamplesBin64>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. 

Если вы просмотрите исходный код, расположенный по адресу C:Program FilesIBMMQToolscSamplesBin64amqssslc.c вы можете видеть, что он делает следующее:

1. Если имя администратора очередей не указано, имя администратора очередей будет установлено на NULL и распечатать Connecting to the default queue manager
2. Если имя подключения не указано, настройка ClientConn, а также ConnectOptions.ClientConnPtr остается по умолчанию NULL значение, он напечатает No client connection information specified.
3. Если указана основа репозитория ключей SSL, он установит SslConnOptions.KeyRepository к этому значению и распечатайте Using SSL key repository stem а затем укажите ConnectOptions.SSLConfigPtr к SslConnOptions.

После всего этого он выдает MQCONNX и указывает NULL имя администратора очередей и ConnectOptions. Поскольку ConnectOptions.ClientConnPtr остается по умолчанию NULL value MQ попытается выяснить, как подключиться к диспетчеру очередей несколькими другими способами. Порядок и место поиска информации о подключении задокументированы на странице центра знаний IBM v7.5 (или новее) «Подключение клиентских приложений IBM WebSphere MQ MQI к администраторам очередей». В вашем случае он забирает файл CCDT.

Если вы не укажете имя администратора очередей, он ищет запись в CCDT с пустым QMNAME атрибут и находит CLNTCONN канал, который вы определили, где QMNAME пусто. Пустой QMNAME на CLNTCONN канал — это особый случай, когда клиент MQ будет подключаться к любому администратору очередей с именем, которое прослушивает CONNAME что вы укажете. Поскольку вы указываете основу репозитория ключей SSL, он будет использовать этот репозиторий ключей для подключения к MQ с помощью SSLCIPH вы указали на CLNTCONN в CCDT.

Когда ты делать укажите имя администратора очередей FOO, он пытается найти запись в CCDT с QMNAME атрибут установлен на FOO, в вашем случае его не существует, поэтому вы получаете 2058 или MQRC_Q_MGR_NAME_ERROR ошибка.

На основании вашего обновления на канале CCDT есть пустое поле. QMNAME атрибут и CONNAME перечисляет два разных IP (ПОРТА), разделенных общим. С этой конфигурацией MQ сначала попытается подключиться к первому IP-адресу, если время ожидания соединения истекло или завершилось по какой-либо другой причине, например, когда канал в диспетчере очередей находится в состоянии ОСТАНОВЛЕН, он затем попытается подключиться ко второму IP-адресу.

Вполне возможно, что они намереваются для вас подключиться с пустым или NULL именем администратора очередей из-за того преимущества, что клиент будет подключаться к любому администратору очередей с именем, которое прослушивает CONNAME, в вашем случае первый IP (PORT) может быть администратор очередей FOO, а второй IP (ПОРТ) может быть администратором очередей BAR.

Если вы хотите, чтобы он работал с вашей CCDT, когда вы указываете -m FOO вам нужно будет либо создать новую CCDT с CLNTCONN канал с QMNAME(FOO), или добавить другой CLNTCONN канал к существующей CCDT с QMNAME(FOO), обратите внимание, вы не можете иметь повторяющиеся имена каналов в одной CCDT.

Для получения дополнительной информации о CCDT и указании имени администратора очередей см. Мой ответ на «Подключение к IBM MQ с помощью файла CCDT в JMS». Ответ относился к JMS, но информация применима и к клиентам MQI.

У вас также есть возможность указать все детали в командной строке, как сказал Роджер. Бегать amqssslc.exe ? для информации об использовании это должно выглядеть так:

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] 

• Спасибо за обстоятельный ответ. Файл CCDT был предоставлен поставщиком, поэтому мне нужно дождаться ответа от него, прежде чем я смогу подтвердить.
• Я использую версию v9. Результаты, которые я получаю при выполнении предложенной вами команды, возвращают пустое имя QM. Означает ли это, что поставщик не включил необходимую информацию в предоставленный им файл CCDT? 5724-H72 (C) Copyright IBM Corp. 1994, 2016. Запуск локального MQSC для MYQUEUE.TAB. 1: DIS CHL (*) QMNAME CONNAME AMQ8414: отображение сведений о канале. CHANNEL (FOOCHANNEL) CHLTYPE (CLNTCONN) CONNAME (xxx.xxx.xxx.xxx (1414), xxx.xxx.xxx.xxx (1414)) QMNAME () Нет команд с синтаксической ошибкой.
• Приношу свои извинения за форматирование — SO не поддерживает разрывы строк в комментариях.
• Да, проблема решена. Я отмечу ваш как ответ и дополню свой вопрос дополнительной информацией. Спасибо за помощь.
• 1 @kiprainey, рад, что это помогло. Я основываюсь на том, что CONNAME содержит два IP / порта, тогда вполне может быть, что каждая комбинация IP / PORT является другим QMNAME, и, указав пустое значение для этого значения, вы можете подключиться к любому администратору очередей. Я собираюсь очистить некоторые старые комментарии выше, которые относятся к вашему вопросу и моему ответу.

Я испытываю странное поведение при запуске базовых тестов подключения с моей рабочей станции на удаленный сервер MQ.

Это не программа. Вы не указали достаточно параметров. Вы запускали «amqssslc.exe?» или посмотреть исходник? т.е. amqssslc.c

Где название канала? Где имя подключения? Где CipherSpec? так далее…

• 2 Можно подключиться вообще без параметров, например amqssslc.exe. Указанные вами параметры находятся в файле CCDT.
• После того, как JoshMc объяснит вам это, вы решите ответить CCDT. Конечно, если вы использовали файл CCDT, тогда возникает вопрос: «Почему вы также не поместили в него хранилище ключей?».
• В системах Windows на репозиторий ключей часто ссылаются как на переменную среды.