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.
Related
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.
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.
I create a queue manager like QMTEST in IBM WebSphere MQ Explorer. I want to connect to a remote queue manager (remote ip address). I followed these steps:
add remote Queue manager
Queue manager name: QMTEST [Next]
Host Name or ip Address: X.X.X.X(remote ip) [Finish]
But I couldn't connect. I got this error message 'Could not establish connection to the queue manager-reason 2538.(AMQ4059)'. What can I do?
The four digit number in your error message is an MQRC (MQ Reason Code). This number gives you more information about what went wrong. You can look it up in Knowledge Center.
MQRC_HOST_NOT_AVAILABLE (2538)
There is a list of possible things that could cause this error. My guess is it is likely to be the first one, you have not started a listener on the queue manager, since you do not mention doing that in your question details.
You should also read the following link which is some basic details on how to connect to a remote queue manager. You appear to have the MQ Explorer side sorted, but perhaps not the queue manager side.
Setting up the server using the command line
Please ensure the listener is running on the remote queue manager side. The default MQ listener port is 1414. If the listener is running then check the queue manager error logs for any connection errors from the MQ explorer.
Are you sure the qmgr and its listener are running and that you have a SYSTEM.ADMIN.SVRCONN channel? That is the server-connection channel used for remote administration of a queue manager. This technote may be helpful.
Is this on a modern Windows or Linux server? If so, did you open the port (i.e. 1414) in the firewall?
Sometimes when we create a Queue manager remote administration objects are not created that's why we get such errors because it is unable to find these objects. To create them right click on the queue Manager, Select Remote Administration objects and create them and start the listener.
I experienced this same error and the queue was configured correctly.
I was using Eclipse and switched to the MQ Explorer setup available from IBM web page.
After that, I was totally able to see the queues and everything I was supposed to see.
We are using WebSphere MQ client adapters on an AIX box to send messages via MQ. We send them to the outbound remote queue on the same box and find it quite slow to get to their destination - a 27mb file takes 3 minutes to run the MQQueue.put command.
Bizarrely we can change the send parameters to send to an outbound remote queue on an entirely different box and it will send the file in 2 seconds. Similarly coming back to this box from elsewhere will be quick. And sending from another box to the outbound remove queue on that same box is also slow.
So in summary the problem appears to be when sending to the outbound remote queue on the same box - we have tried specifying the destination by dns name, ip address, 127.0.0.1 etc, but no luck.
Would be grateful for any advice.
Try see if tcp_nodelayack makes a difference on the box. If you are at a new enough MQ level (which one are you at?) then you can just set MQ_SET_NODELAYACK to affect just MQ or alternatively (or for a quick test) just set it system wide on AIX with the 'no' command listed in the first link below.
See http://www-01.ibm.com/support/docview.wss?uid=swg21320862
FYI apar which adds the MQ specific env var option
http://www-01.ibm.com/support/docview.wss?uid=swg1IZ43635
As an aside I'd also recommend trying MQ v8 client to stop MQ playing with the buffer sizes and let the o/s default them, but from the sounds of your problem I would not be surprised if the above helps.
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.