I Am using Java application to connect to WMQ so as to create test suite, which pass message from a file to queue and wait for response from other queue, I am using WMQ V7.0 and ih03_RFHutil package provided by IBM, but after configuring every thing correctly I am getting below error message. It looks like some Authentication issue. Can some one please help me in this.
Below is Logs I have taken using log4j:
2017-03-06 17:26:01 DEBUG Runner_TMH_Tester:108 - initial sleep time 20 tune = 0
2017-03-06 17:26:01 DEBUG Runner_TMH_Tester:108 - connecting to TESTQMGR
2017-03-06 17:26:01 DEBUG Runner_TMH_Tester:108 - MQSeries error with MQCONN on TESTQMGR - compcode = 2, reason = 2058
MQ v7.0 was released June 27th 2008 and has been out of support since September 30th 2015 (almost 1.5 years). The version probably does not have anything to do with your issue but I would strongly suggest that you move to a supported version of the MQ client. Newer MQ client versions can connect to older MQ queue managers. You can download a java only install of MQ 8.0 or MQ 9.0 jar files at the links below:
IBM MQ v8.0 Client
IBM MQ v9.0 Client
The MQ client and queue manager install come with a program called mqrc. You can run this against the MQ return code, in this case 2058 to come up with a more meaning full description:
$ mqrc 2058
2058 0x0000080a MQRC_Q_MGR_NAME_ERROR
This is telling you that TESTQMGR is not the name of the queue manager that exists on the host and port you are connecting too. Verify the queue manager name, hostname, and port are all correct.
Related
We have an application that uses WebSphere MQ 7.0.1.3. During extensive testing in our stage environment, the disks became full.
After this, the MQ is hanging. We removed the application logs (not related to MQ) and added more disk but it didn't solve the problem.
We tried to restart the queue manager:
$ endmqlsr
$ endmqm XYZ
$ strmqm XYZ
WebSphere MQ queue manager 'XYZ' starting.
WebSphere MQ was unable to display an error message 893.
The logs from the time when the disk became full and the error occurred:
----- amqxfdcx.c : 828 --------------------------------------------------------
06/08/2018 03:36:44 AM - Process(8832.5) User(mqm) Program(amqzlaa0)
AMQ6119: An internal WebSphere MQ error has occurred (Rc=28 from write)
----- amqxfdcx.c : 783 --------------------------------------------------------
06/08/2018 03:36:44 AM - Process(8832.5) User(mqm) Program(amqzlaa0)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager XYZ.
----- amqxfdcx.c : 822 --------------------------------------------------------
06/08/2018 03:36:46 AM - Process(8832.5) User(mqm) Program(amqzlaa0)
AMQ6119: An internal WebSphere MQ error has occurred (Rc=28 from write)
----- amqxfdcx.c : 783 --------------------------------------------------------
06/08/2018 03:36:46 AM - Process(8832.5) User(mqm) Program(amqzlaa0)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager XYZ.
AMQ6119: An internal WebSphere MQ error has occurred ('28 - No space left on device' from semget.)
----- amqxfdcx.c : 783 --------------------------------------------------------
06/14/2018 02:35:46 PM - Process(6794.1) User(mqm) Program(amqzxma0)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager XYZ.
----- amqxfdcx.c : 822 --------------------------------------------------------
06/14/2018 02:35:46 PM - Process(6794.1) User(mqm) Program(amqzxma0)
AMQ6118: An internal WebSphere MQ error has occurred (20006037)
When trying to connect with the IBM WebSphere MQ Explorer
Queue manager not available for connection - reason 2059. (AMQ4043)
Severity: 20 (Error)
Explanation: The attempt to connect to the queue manager failed. This could be because the queue manager is incorrectly configured to allow a connection from this system, or the connection has been broken.
Response: Ensure that the queue manager is running. If the queue manager is running on another computer, ensure it is configured to accept remote connections.
Is there a way of clearing all messages from the queues and resetting all flags so the queue manager will start and the queues will work again?
There are only old test data in the queues, nothing of value.
Or do you have any other suggestions on how to fix this?
You can use the mqrc command to provide more information on errors. Most of the time MQ reports return codes as a four digit decimal number. In this case since the return code is three digits it usually (always?) means it is a HEX return code.
$ mqrc 2195
2195 0x00000893 MQRC_UNEXPECTED_ERROR
This error is thrown when MQ hits an error condition that was not expected. Usually you will find a FDC file was created in the /var/mqm/errors directory that could provide some more detail.
The best course of action when you receive this type of error is to open a PMR with IBM and have them provide direction on recovery to ensure you have the best chance of preserving messages that may be present on your queues, however you are using a version of MQ (7.0) that has been out of support since September 30th 2015. The specific Fix Pack you are on (7.0.1.3) was released in August 2010. The last release of v7.0 from IBM was 7.0.1.14 in August 2016.
If you pay IBM for extended support you may be able to open a PMR with them for futher support.
The best path forward once you have resolved your issue would be to migrate to a supported version of IBM MQ. Currently v8.0 and v9.0 are the only supported versions of IBM MQ at this time.
Assuming you do not have extended support and are unable to get assistance from IBM, the following are some suggested steps:
Updating even to the latest Fix Pack (7.0.1.14) may help, and if it does not solve the problem it is still better by be at the latest Fix Pack of a unsupported version of IBM MQ.
You could try to cold start your queue manager and see if that helps. This is documented starting on Page 4 of the presentation "WebSphere MQ Disaster Recovery" given by Mark Taylor at Capitalware's MQ Technical Conference v2.0.1.3.
Create a queue manager EXACTLY like the one that failed
Use qm.ini to work out parameters to crtmqm command
Log:
LogPrimaryFiles=10
LogSecondaryFiles=10
LogFilePages=65535
LogType=CIRCULAR
Issue the crtmqm command
crtmqm -lc -lf 65535 -lp 10 -ls 10 –ld /tmp/mqlogs TEMP.QMGR
Make sure there is enough space for the new log files in that directory
Name of the dummy queue manager is irrelevant
Only care about getting the log files
Don’t start this dummy queue manager, just create it
Replace old logs and amqhlctl.lfh with the new ones
cd /var/mqm/log
mv QM1 QM1.SAVE
mv /tmp/mqlogs/TEMP!QMGR QM1
Note the “mangled” directory name … this is normal
Data in the queues is preserved if messages are persistent
Object definitions are also preserved
Objects contain their own definitions in their files
Mapping between files and object names held in QMQMOBJCAT
Once all the above is complete then try and start your queue manager.
Guys I am trying to connect to MQ Hub from WAS Liberty application. Our MQ Hub supports only SSL certificate authentication. I have created QCF, Keystore with JKS file and with certificate inside it. Then I created defaultSSLConfig and pointed to that keystore.
But I could not find anyway to specify the SSLConfig in the QCF and read on some page that it was not possible. The only way was to use defaultSSLConfig and specify keystore from there which I did. So now I am here and MQ connection does not work. On the MQ Hub logs I see the error saying that "The channel is lacking a certificate to use for the SSL handshake."
This is how my QCF looks like, no parameter to specify an SSL config
<jmsConnectionFactory connectionManagerRef="ConMgr" jndiName="jms/wmqCF">
<properties.wmqJms channel="TEST_CHANNEL" hostName="REMOVED" port="1415" queueManager="ALQ.TEST" transportType="CLIENT" sslCipherSuite="SSL_RSA_WITH_AES_128_CBC_SHA"/>
</jmsConnectionFactory>
Full error on MQ side
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The
channel
name is 'XXX.ADM.SVRCONN' (if '????' it is unknown at this stage in the
SSL
processing).
The remote host is 'XXX (10.xx.xx.x)'.
The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the
key
repositories for both ends of the channel.
----- amqccisa.c : 7355
02/14/17 15:07:44 - Process(7510.304808) User(mqm) Program(amqrmppa)
Host(xxx) Installation(Installation1)
VRMF(7.5.0.6) QMgr(XXXXX)
AMQ9999: Channel 'XXX.ADM.SVRCONN' to host 'xxx (10.xx.xx.xx)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 7510 for channel 'XX.ADM.
SVRCONN'
ended abnormally. The host name is 'xx (10.xx.xx.xx)'; in some
cases the
host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error
logs to
determine the cause of the failure. Note that this message can be
excluded
completely or suppressed by tuning the "ExcludeMessage" or
"SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information
can be
found in the System Administration Guide.
It is working now :) What we think was the cause of the problem is this bug http://www-01.ibm.com/support/docview.wss?uid=swg1IT16056
Although the error in APAR above is not the same I was getting. I was seeing this error on the Liberty (client side)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with
compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.
java:203)
I was using this resource adapter when the problem was manifesting itself: 9.0.1.0-IBM-MQ-Java-InstallRA.jar
Then we decided to try lower version of the adapter which had that APAR/fix in it and thus used this one: 8.0.0.6-WS-MQ-Java-InstallRA.jar
So that solved the problem.
I was pretty sure that the above bugfix was included in Ver 9.X of the resource adapter but as it turns out it is not the case.
I checked with IBM and they confirmed that APAR IT16056 is not included in the 9.0.1.0 CD release. They are working to correct the APAR to show the right target release for the fix.
Quote from IBM support is below.
I can confirm that the APAR in question, "IT16056" is NOT included in
the 9.0.1.0 CD release, and is currently targeted to be included in
the 9.0.2.0 CD release.
Based on this if you want you use a version of the RA higher than 8.0 you would need to do one of the following:
Wait until the 9.0 LTS (Long Term Support) 9.0.0.1 fixpack is released (IBM has a site where they list they are targeting 1Q 2017).
Wait until the 9.0 CD (Continuous Delivery) 9.0.2.0 release is out (IBM does not publish a target for CD)
Open a PMR to IBM and ask them for a IFIX to apply the 9.0.0.1 LTS or 9.0.1.0 CD release.
I am using IBM Websphere MQ 7.5 in Unix system. I have installed the client on my machine and server is running on other machine. I am observing a scenario where I am able to communicate with server when running my JMS application via 'mqm' user but facing below mentioned error when using other user.
But I am able to run 'amqsputc' and 'amqsgetc' command and communicate with the server with mqm as well as other user also. I have followed all steps mentioned http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ins.doc/q009300_.htm?lang=en
Exception:
com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'TestManager' with connection mode 'Client' and host name 'x.x.x.x(9923)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:521)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:221)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:426)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:6902)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:6277)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:285)
at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6233)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:120)
at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:203)
at performance.IBMMQTestProducer.start(IBMMQTestProducer.java:142)
at performance.IBMMQTestProducer.main(IBMMQTestProducer.java:177)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').**
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:209)
... 9 more
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2035;AMQ9509: Program cannot open queue manager object. [1=2035,5=???]**
at com.ibm.mq.jmqi.internal.JmqiTools.getQueueManagerInfo(JmqiTools.java:783)
at com.ibm.mq.jmqi.remote.impl.RemoteSession.loadInfo(RemoteSession.java:1993)
at com.ibm.mq.jmqi.remote.impl.RemoteSession.getName(RemoteSession.java:2026)
at com.ibm.mq.jmqi.remote.api.RemoteHconn.getName(RemoteHconn.java:728)
at com.ibm.mq.ese.intercept.JmqiConnInterceptorImpl.validate(JmqiConnInterceptorImpl.java:321)
at com.ibm.mq.ese.intercept.JmqiConnInterceptorImpl.afterConnect(JmqiConnInterceptorImpl.java:226)
at com.ibm.mq.ese.intercept.JmqiConnInterceptorImpl.afterJmqiConnect(JmqiConnInterceptorImpl.java:133)
at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJmqiImpl.java:315)
at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:337)
I am able to run it when I am running as myself and passing 'mqm' when starting the connection.
connection = cf.createConnection("mqm", "pswd");
I am not getting anything in manager's log. Below is the log.
------------------------------------------------------------------------------
10/30/2015 06:50:54 AM - Process(31064.1) User(mqm) Program(strmqm)
Host(x.x.x.x) Installation(Installation1)
VRMF(7.5.0.2)
AMQ7125: There are 83 days left in the trial period for this copy of WebSphere
MQ.
EXPLANATION:
This copy of WebSphere MQ is licensed for a limited period only.
ACTION:
None.
Given that you have told us that you have successfully connected and run the amqsgetc and amqsputc client samples using the same server-connection channel as you are attempting to use for your JMS program that suggests that this is not a connection time problem, in other words the MQCONN to the queue manager has been successful and something following that is failing. We know that you can MQPUT and MQGET (since that is what the aforementioned samples do).
Something that JMS does that those simple samples do not do, is an MQINQ of the queue manager. The following part of your exception makes me wonder if that is what you are tripping over:-
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2035;
AMQ9509: Program cannot open queue manager object. [1=2035,5=???] at
com.ibm.mq.jmqi.internal.JmqiTools.getQueueManagerInfo(JmqiTools.java:783) at
To be completely certain you must check the queue manager AMQERR01.LOG to see what is reported there. If it is missing authorization then it will tell you there.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
We are have a IBM websphere MQ[v5.2] on AIX platform and my machine is windows 7 pro which has MQ client v7.5.
I tried to connect to server remotely but i received a Authorization error message. This is because my local user account does have rights to connect to queue manager remotely.
So,i created a new user account in my system with some name as on server which has rights to put/get message and now i am able to connect in client mode[Websphere MQ v7.5].
I don't know whether it is actually connecting to server but it is not giving me authorization error message so i took it as success. But the issue is, when I tried to put message into queue from cmd using amqsputc Queue_name mqm the queue is opening and taking a message. But when i tried to get the message using command amqsgetc queue_name mqm it says "NO MORE MESSAGE".
What could be the issue?
Screen shot:
The fact the amqsputc doesnt give an error, and the fact the amqsgetc runs through to success implies the functionality is working. However, it finds nothing on the queue which makes me very suspicious that you have an application listening on that queue, which will consume the message as it arrives and hence before your amqsgetc. Check DISPLAY QSTATUS in runmqsc for IPPROCS on the queue - is it 0 when amqsgetc isnt running?