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.
Related
We've tryed to test connection to the remote queue manager after installing MQ client v7.5 on Windows Server 2019. We've used Rfhutilc for this and got 'Host not available' inspite of the fact that telnet connection to the corresponding address was succecfully established. Also we tryed to connect using MQ client v9.0 with the same result.
AMQERR01.LOG (client v.7.5) reported following details:
29.09.2020 15:36:10 - Process(10828.2) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9208: Error on receive from host 'X.X.X.X'.
EXPLANATION: An error occurred receiving data from 'X.X.X.X' over TCP/IP. This may be due to a communications failure.
ACTION: The return code from the TCP/IP recv() call was 10054 (X'2746'). Record these values and tell the systems administrator.
----- amqccita.c : 4065 -------------------------------------------------------
29.09.2020 15:37:56 - Process(10828.1) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9202: Remote host 'X.X.X.X' not available, retry later.
EXPLANATION: The attempt to allocate a conversation using TCP/IP to host 'X.X.X.X' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
ACTION: Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 10060 (X'274C'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host 'X.X.X.X' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.
Here is an example of how traffic data looks like when Rfhutilc refuses to connect to the queue.
As soon as according to the picture there was some code page issue we've tryed to set MQCCSID environment variable with the value 1208 and it helpled.
Also connection attempt via Rfhutilc was succeful while running under another user with login "admin" even though without setting MQCCSID variable.
But I failed to find explanation for this. Did the CCSID of the MQ client differ from system code page of what? And how could I find out default CCSID of MQ client then?
MQ client v7.5 worked just fine on the Windows Server 2012 R2 right after installing. Rfhutilc v7.5 was used both on Server 2012 and Server 2019 for testing.
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.
I'm using MongoDBs on three different computers only accessible by IPV6.
I'm able to connect to those DBs using php5 driver, command line interface (with the option --ipv6) and an UI app called "MongoHUB".
The only driver unable to connect thru IPV6 is the ruby one.
Any tip using it, for example, does exist an option when creating a MongoClient by uri stating the address is an ipv6 one, as with command line ?
The MongoDB Ruby driver doesn't support IPv6 yet (just an oversight/no one had requested it), but it will be fully supported in our next release.
Add yourself as a watcher to this ticket here to follow the progress:
https://jira.mongodb.org/browse/RUBY-700
My problem is that I have two servers, one running MQ Server and one running service which will get MQ messages from the former. However easily it sounds, I cannot make the latter to connect to the queue manager on the first server. I tried the following actions:
Ping the first server from the second one: it works just fine
Telnet the first server from the second one, using specific port used to connect MQ Manager on the first server (1416): it also works find
Now it comes the weird part: I created one Queue Manager on the second server (there is also a MQ Server running on that machine), with the same name with the MQ Manager on the first server that I want to connect, then I can only connect to this queue, although in the ChannelInfo I specify exactly the first server's IP address, not the second's.
After deleting the MQ Manager on the second server, it just gives me error 2058: MQRC_Q_MGR_NAME_ERROR. I checked the MQ Mananer name on the first server, it was correct.
It is possible to connect from other servers to the first server's MQ Manager.
More information that I doubt it is the source of my problem: the first server running Windows 32 bits and the second one is running Windows 64 bits. Moreover the second one is fresh installed, so I think it might have problem with some sorts of permissions. However searching around didn't help me so far.
I really appreciate if someone here could shed some lights on my problem. It made my project overdue deadline for a week already.
Thanks in advance!
No the error is not due to 32/64 bit Windows platform.
On both 32 bit as well as 64 bit Windows platforms queue manager runs as a 32 bit process.
So that's not the issue.
Obvious things to verify on the first server:
Have you defined a listener for the queue manager to listen on port 1416? If yes, is it running?
Have you defined a server connection (SVRCONN) channel on the queue manager?
How does your service(running on second server) attempt to connect to the queue manager? Is it bindings or client mode? In bindings mode, an application can connect only to the queue managers running on the same machine. In client mode, applications can connect to queue manager running on the same machine or a different machine. Your service must use a client mode connection to connect to remote machine.
To connect to remote queue manager, the application must specify the host name, port and channel name.
stupid problem. I get those from a client connecting to a server. Sadly, the setup is complicated making debugging complex - and we run out of options.
The environment:
*Client/Server system, both running on the same machine. The client is actually a service doing some database manipulation at specific times.
* The cnonection comes from C# going through OleDb to an EasySoft JDBC driver to a custom written JDBC server that then hosts logic in C++. Yeah, compelx - but the third party supplier decided to expose the extension mechanisms for their server through a JDBC interface. Not a lot can be done here ;)
The Symptom:
At (ir)regular intervals we get a "Address already in use: connect" told from the JDBC driver. They seem to come from one particular service we run.
Now, I did read all the stuff about port exhaustion. This is why we have a little tool running now that counts ports and their states every minute. Last time this happened, we had an astonishing 370 ports in use, with the count rising to about 900 AFTER the error. We aleady patched the registry (it is a windows machine) to allow more than the 5000 client ports standard, but even then, we are far far from that limit to start with.
Which is why I am asking here. Ayneone an ide what ELSE could cause this?
It is a Windows 2003 Server machine, 64 bit. The only other thing I can see that may cause it (but this functionality is supposedly disabled) is Symantec Endpoint Protection that is installed on the server - and being capable of actinc as a firewall, it could possibly intercept network traffic. I dont want to open a can of worms by pointing to Symantec prematurely (if pointing to Symantec can ever be seen as such). So, anyone an idea what else may be the cause?
Thanks
"Address already in use", aka WSAEADDRINUSE (10048), means that when the client socket prepared to connect to the server socket, it first tried to bind itself to a specific local IP/Port pair that was already in use by another socket, either an active one or one that has been closed but is still in the FD_WAIT state. This has nothing to do with the number of ports that are available.
I'm having the same issue on a Windows 2000 Server with a .Net application connecting to a SQL Server 7.0. There's like 10 servers with the same configuration and only one is showing this error several times a day. With a small test program I'm able to reproduce the error by just establishing a TCP connection on the SQL Server listening port. Running CurrPorts (http://www.nirsoft.net/utils/cports.html) shows there's still plenty of available ports in range 1024-5000.
I'm out of ideas and would like to know if you've found a solution since you've posted your question.
Edit : I finally found the solution : a worm was present on the server (WORM_DOWNAD.A) and exhausted local ports without being noticed.