RE: .NET Data Provider and CPE3426

Sounds to me like a communications failure perhaps between IBMi and the Windows machine.

Should be essentially using the same connections as ODBC and OLEDB and perform the same as well.

Might need to reach out to IBM if you can't solve it.

Service packs on CA/400 perhaps ?

Bad cabling or bad router ?

Regards,

Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

------------------------------

message: 3
date: Fri, 23 Dec 2016 09:54:57 -0800
from: Jerry Draper <midrangel@xxxxxxxxxxxxx>
subject: .NET Data Provider and CPE3426

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.)