II11670: MSGDSNL511I RC=140 for TCP PIPE BROKEN or RC=1121 CONNECTION RESET by PEER. APPLICATION RECEIVED ABEND04E RC00E50013

APAR status

• Closed as canceled.

Error description

• Distributed environment from Workstation with Microsoft
  application using Stored Procedure via DB2 Connect V5
  with TCPIP stack 3.2 to DB2/MVS V5 for OS/390 V2.4.
  .
  Application received ABEND04E RC00E50013 on DB2/MVS and
  the SYSLOG had the following messages depending on the
  SQL activity:
  .
  DSNL511I -DB2M DSNLIENO TCP/IP CONVERSATION FAILED
         TO LOCATION 165.175.217.36
         IPADDR=165.175.217.36 PORT=1223
         SOCKET=WRITEV RETURN CODE=140 REASON CODE=12EE0291
                     (WRITEV rc140 rsn12EE0291)
  
  DSNL511I -DB2M DSNLIENO TCP/IP CONVERSATION FAILED
         TO LOCATION 165.175.217.36
         IPADDR=165.175.217.36 PORT=4780
         SOCKET=READ RETURN CODE=1121 REASON CODE=12EE0291
                     (READ rc1121 rsn12EE0291)
  
  PTFs were applied in II11164.
  ***************************************************************
  * TCPIP support suggested running NETSTAT,CONN command on TSO*
  * for network status, MAXSOCKET=10,000 and PORTRANGE defined  *
  * in TCPIP PROFILE.TCP.                                       *
  ***************************************************************
  The RC=140 is for pipe broken and RC=1121 is for connection
  reset by peer.
  TCPIP and OE support reviewed the TCPIP Moretrace and OE
  Ctrace and SLIP trap data for OMVS, TCPIPOE, DB2 MSTR and
  DIST address space dumps and concluded that this connection
  was reset by the workstation.
  .
  Workstation support reviewed the DB2TRC trace and confirmed
  this is reset by exceeding the timeout limit.
  The customer found out this problem correlates to the
  ODBC timeout value. They discovered they have not set
  the timeout value correctly. In the Microsoft ActiveX
  Data Objects (ADO) world, the ODBC timeout value can
  be set on both the "connection" object and the
  "command" object. They assumed "command" timeout will
  inherit the set "connection" timeout value which is
  not the case.
  .
  So, the workaround is to use QUERYTIMEOUTINTERVAL=0
  in DB2CLI.INI file to globally override any of the
  timeout value being set.
  .
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Closed for Internet viewing
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels