There is a queue manager which runs with CCSID 437, and i would like to connect remotely to the queue manager via MQ Explorer. I got this error:
AMQ6047E: Conversion not supported.
EXPLANATION:
IBM MQ is unable to convert string data tagged in CCSID 437 to data in CCSID
1208.
My first debugging try was connecting to the queue manager with mqsc console. And "alter qmgr ccsid(1208) force" even with this i couldn't connect. (i did a restart). And the issue was the same.
However, i seen another queue manager which runs with ccsid (819), but there wasn 't any issue with connecting.
IBM MQ version 9.1
OS: AIX 7.1
Any idea that can solve this issue?
If i change ccsid(437) to 819. Applications could connect again to the queue manager without a problem?
Thanks a lot.
MQ relies on the AIX base operating system to perform data conversion on its behalf. In order to support Unicode conversion AIX provides several optional filesets:
bos.iconv.ucs.com Unicode converters for AIX sets
bos.iconv.ucs.ebcdic Unicode converters for EBCDIC sets
bos.iconv.ucs.pc Unicode converters for PC sets
You should install these filesets from the AIX operating system installation media if you need to convert data to and from Unicode on your system.
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.
Alter channel page https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q085170_.htm shows that I can use Disconnect interval (DISCINT) in server connection channel alter command, however I get error message which claims that it can only be used for server or sender channel types, but not for server connection channel types.
Maybe MQ command level is too low for DISCINT attribute? How can I check that?
Operating System is Linux for that particular workgroup server...
This knowledge center page for MQ v 7.0.1 indicates that alter chl DISCINT is only valid on zOS.
Also, this page says: This attribute is valid for channel types Server connection (z/OS® only)
Maybe you are using an older version of MQ? There are many different ways to check your MQ version - from the command line try dspmqver.
The other day i tried to add new remote MQGR through MQ explorer but it failed with below error:
AMQ4052 Coded character set ID error. Cannot convert a command message to the CCSID of the target queue manager.
The ccsid used by remote QMGR is 5488, and the ccsid of local pc where the MQ explorer installed is 1381, i suppose.
My question is:
How to configure the value of ccsid used by MQ Explorer?
What kind of ccsid am i supposed to select for MQExplorer in order to communicate with remote QMGR? Besides this, where can i find the information about the ccsid compatibility?
From the MQ perspective, when communicating through client and server, what is the procedure to check CCSID compatibility? I know the MQ has data conversion table installed on OS, such as files under /usr/lib/nls/loc/iconvTable for AIX. Then how does the MQ make use of it?
Thanks in advance
You can set your environment variable MQCCSID.
The supported conversions depend on the platform the queue manager is running on, see Code Page Conversions for a list of supported conversions.
as far as I know, it uses iconv on Unix, I don't know how it handles that on Windows exactly.
I have now tried 2 days to connect to external DB2 database with SQuirreL. I always get error:
[jcc][t4][2030][11211][3.58.82] A communication error occurred during operations
on the connection's underlying socket, socket input stream, or socket output
stream. Error location: Reply.fill(). Message: Insufficient data.
ERRORCODE=-4499, SQLSTATE=08001
I am using IBM DB2 Universal JDBC driver v9.7 FP5. I have as well tried v9.5.
One thing is that the DB2 is tunneled with Putty. Server runs linux with IBM DB2 v7.1. I am using Win7x64.
I have ran over many forum topics on the web which cover this error, but none of them has actually worked for me. (ie. iReport to DB2 connection ERRORCODE=-4499, SQLSTATE=08001)
First I thought that maybe this related to port that isn't corretcly tunneled. But I removed the port from Putty session conf and different error occured.
Stack trace as well for the problem:
com.ibm.db2.jcc.am.io: [jcc][t4][2030][11211][3.58.82] A communication error
occurred during operations on the connection's underlying socket, socket input
stream, or socket output stream. Error location: Reply.fill(). Message:
Insufficient data. ERRORCODE=-4499, SQLSTATE=08001
at com.ibm.db2.jcc.am.ed.a(ed.java:319)
at com.ibm.db2.jcc.t4.a.a(a.java:416)
at com.ibm.db2.jcc.t4.a.a(a.java:411)
at com.ibm.db2.jcc.t4.cb.b(cb.java:227)
at com.ibm.db2.jcc.t4.cb.c(cb.java:249)
at com.ibm.db2.jcc.t4.cb.c(cb.java:360)
at com.ibm.db2.jcc.t4.cb.v(cb.java:1145)
at com.ibm.db2.jcc.t4.db.a(db.java:42)
at com.ibm.db2.jcc.t4.b.m(b.java:1238)
at com.ibm.db2.jcc.t4.b.b(b.java:1112)
at com.ibm.db2.jcc.t4.b.c(b.java:700)
at com.ibm.db2.jcc.t4.b.b(b.java:686)
at com.ibm.db2.jcc.t4.b.a(b.java:367)
at com.ibm.db2.jcc.t4.b.<init>(b.java:307)
at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection(DB2SimpleDataSource.java:214)
at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:456)
My best guess was and is still that JDBC universal driver is not backward compatible with DB2 v7.1.
It works on an other development machine (coworker) with 32bit XP on it. I have tried to put it working on different 32bit XP but the same result occurs.
Can anyone at least describe the root of this anomaly?
Edit
http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14779629
This cannot be a firewall or tunneling error. Successfully opened a tunnel to correct port with telnet.
You need to locate and use the DB2 7.2 or DB2 7.1 client code (aka DB2 Client Application Enabler). Prior to DB2 8.1, IBM used a different, platform-dependent protocol called DB2RA for communication between the client and server. DB2 8.1 switched to the standard DRDA protocol. DB2 8.x clients could, in specific configurations, talk to DB2 7.x servers.
Alternatively, if you are using a Java application, you could try to locate/use the Type 3 JDBC driver (COM.ibm.db2.jdbc.net.DB2Driver). This driver is clientless (it has a 3-tier architecture, because it requires a so-called "JDBC Applet Server" to be running on the database server. You can see if it's running on your linux box by looking for a process called db2jd. Generally this process will show up as, for example, db2jd 6789, where 6789 is the port number the applet server is listening on. If you don't see this process you can start it (as the DB2 instance owner) by executing the db2jstrt command.
Another possibility: You may need to restart the computer. In my case, this worked for me. I got this error after installing a special build of DB2 10.5.
For more diagnostics, you can get your IBM JDBC driver version using: java com.ibm.db2.jcc.DB2Jcc -version
Or, try: java -cp ./db2jcc.jar com.ibm.db2.jcc.DB2Jcc -version. Then co-relate the driver version to the Db2 version. Link with more details.