II14769: MESSAGE DSNL511I SOCKET=READ RETURN CODE=0 REASON CODE=00000000 AFTER MIGRATING TO DB2 11 FOR Z/OS

APAR status

• Closed as canceled.

Error description

• 5740XYR00 DB2DDF DB2TCPIP DB2DRDA
  A DSNL511I READ 0/00000000 message usually indicates that a
  remote (requester or server) partner is closing a connection
  while DB2 z/OS (server or requester) is in a Synchronous Read
  socket operation with the remote partner.
  As a result, a DSNL511I READ 0/00000000 condition
  indicates that an unusual event has occurred at the remote
  partner environment. This unusual event will typically be easy
  to identify (for example, perhaps resulting from some cancel
  or abnormal termination related event).
  A DSNL511I message LOCATION value that reflects an IP address
  indicates that the DSNL511I message is being issued by a DB2
  server on behalf of a remote requester partner.
  A DSNL511I message  LOCATION value that reflects an actual
  location name, as defined in SYSIBM.LOCATIONS, indicates that
  the DSNL511I message is being issued by a DB2 requester on
  behalf of a remote server partner.
  .
  DB2 11 for z/OS users may see occurrence(s) of message DSNL511I
  READ 0/00000000 at a DB2 server after migrating to V11 - the
  message(s) did not occur in V10.
   Example:
    DSNL511I  -ssnm DSNLIENO TCP/IP CONVERSATION FAILED
               TO LOCATION ::nn.nn.nn.nnn
               IPADDR=::nn.nn.nn.nnn PORT=pppp
               SOCKET=READ RETURN CODE=0 REASON CODE=00000000
  No unusual events could be identified at the requester partner
  and no requester application failures seemed to occur (or were
  being reported).
  Although no remote application failures could be linked to the
  DSNL511I messages, the source of the DSNL511I was a mystery and
  may cause such a concern when migrating to V11 that it may
  prompt a (unnecessary) fallback to V10.
  In this case, the unusual event is likely related to poor
  behavior of a remote requester application environment. The
  remote application environment would access the DB2 server,
  execute some SQL, and then terminate the connection to the DB2
  server without first completing its active transaction (UOW -
  Unit Of Work) via a commit or rollback.
  In a DB2 10 for z/OS server environment, the receiving of new
  requests during an active transaction is accomplished via an
  asynchronous RECV socket operation. As a result, the connection
  termination event (during an active transaction) would be seen
  via an asynchronous RECV socket operation and hence a DSNL511I
  message would not be issued.
  DB2 11 for z/OS implemented new function to improve the
  performance of active transactions. This is achieved by now
  using a synchronous READ socket operation during active
  transactions. As a result, the connection termination event
  (during an active transaction) will now be seen via a
  synchronous READ socket operation and hence a DSNL511I message
  will now be issued.
  So the poor behavior of the remote application environment has
  likely existed for a very long time but external DB2 for z/OS
  evidence of this poor application behavior has been hidden. Now
  with the new performance improvement feature of DB2 11 for
  z/OS, this poor application behavior is now finally being
  exposed in the form of a DSNL511I READ 0/00000000 message.
  To eliminate the DSNL511I READ 0/00000000 message(s) now being
  encountered after migrating to DB2 11 for z/OS, users should
  correct their poor remote application behavior to end their
  active transaction, via commit or rollback, before terminating
  the connection to the DB2 11 for z/OS server. In fact,
  correcting this poor remote application behavior would also be
  justified relative to DB2 10 (or earlier) for z/OS servers as
  well.
    Note: The current poor application behavior, of terminating
      the connection without first completing its active
      transaction, results in a DB2 for z/OS abort of the active
      transaction. As a result, the application can accomplish
      the same behavior, and avoid any operational risk to the
      application, by driving a rollback to end its active
      transaction.
  When the remote application behavior is changed to first
  complete the transaction (via commit or rollback) before
  terminating the connection, the DB2 11 for z/OS server will
  revert back to an asynchronous RECV socket operation. As a
  result, the connection termination event will be seen via an
  asynchronous RECV socket operation (as in V10 and earlier) and
  hence the DSNL511I message will not be issued.
  In the meantime, until the necessary remote application changes
  can be deployed, users can migrate to DB2 11 for z/OS with the
  understanding that the DSNL511I READ 0/00000000 messages are
  simply indicative of the poor remote application behavior that
  has yet to be corrected but the operational characteristics of
  the remote application itself should not be affected.
  .
  Users should also be aware that the DSNL511I READ 0/00000000
  message condition should disappear after APAR PI47884 and
  PI58082 are applied since these apars together
  introduce a change to utilize a different form of SyncRecv
  that (again, as in V10 and earlier) avoids the message.
  ***************************************************************
  Additional Symptoms and Keywords:
   DSNL511I MSGDSNL511I DSNLIENO SOCKET READ RETURN CODE 0
    REASON CODE 00000000
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Informational APAR.
  

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