I can't say for your ECONNRESET issues, but I will say that the .NET
provider that comes with IBM i Access for Windows does not use OLEDB.
There are 4 database interfaces that come with IBM i Access for Windows:
- jt400 JDBC driver
- .NET data provider
- OLEDB data provider
- ODBC driver
All of these make use of the IBM i database host server interface, which
show up as QZDASOINIT/QZDASSINIT jobs on the IBM i. While the .NET
provider, OLEDB provider, and ODBC driver do share a lot of code in the
underlying libraries, none of them sit above or below each other and the
JDBC driver shares no code with the rest.
We have seen some Firewall/Antivirus software which inserts itself and
messes with the TCP/IP stack on Windows and can cause issues like this. I
don't know if that's what's going on in this case, though - you'd need to
open a PMR for us to investigate further.
----- Original message -----
From: Jerry Draper <midrangel@xxxxxxxxxxxxx>
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc:
Subject: .NET Data Provider and CPE3426
Date: Fri, Dec 23, 2016 11:55 AM
We are having some issues with the .NET Data Provider on V7R1 where we
are getting some CPE3426 errors.
Per Scott Klement's midrange post there are four ways this can happen
(see below).
How can we make the cause of this visible?
The .NET Data Provider uses OLE/db and presents on the I as a QZDASONIT
job. From the I's perspective is this the same as ODBC?
Thanks,
Jerry
*************************
Okay, well I can tell you that errno=3426 is also known as msgid
CPE3426, which is more widely known as ECONNRESET
ECONNRESET means that a TCP connection was closed, and that some of the
sent data was not received.
Four ways this can happen:
1) Receiver does a shutdown() to disable receiving, but sender still
sends data.
2) Receiver disconnects in the middle of a TCP stream, where there's
still data to receive. Normally this doesn't cause ECONNRESET due to
buffering on the receiving end -- but it CAN cause ECONNRESET if
buffering is disabled.
3) Sender sends data then immediately disconnects without waiting for
data to be received. Normally this doesn't cause ECONNRESET because the
OS keeps the TCP connection open even after the socket has closed in
order to send the remainder of the send buffer. But you can tell it not
to wait for the send buffer in your CHGTCPA settings. Or you can kill
the connecting while it's waiting using the NETSTAT command.
4) A hardware failure can cause malformed or misunderstood packets to be
sent in a TCP stream. The receiver would reset the connection to
prevent itself from receiving more of these "damaged" packets. (This
normally means a hardware failure of some kind.)
**********************
--
--
Jerry Draper, Trilobyte Software Systems, since 1976
IBMi, Network, and Connectivity Specialists, LAN/WAN/VPN
Representing WinTronix, Synapse, HiT, and others .....
(415) 457-3431; www.trilosoft.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [1]
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [2]
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: [3]
http://amzn.to/2dEadiD
References
Visible links
1.
http://lists.midrange.com/mailman/listinfo/midrange-l
2.
http://archive.midrange.com/midrange-l
3.
http://amzn.to/2dEadiD
midrange.com
