II11668: MSGDSNL500I SENSE=08640000 RTNCD=00 FDBK2=0B RCPRI=0018 RCSEC=0000 ISSUED AT DB2 DRDA SNA TWO-PHASE SERVER

APAR status

• Closed as canceled.

Error description

• 5740XYR00 DSNL500I MSGDSNL500I 08640000 SENSE08640000
  Also see Information APAR II09330, II11502
  When using DB2 Distributed Data Facility (DDF) DRDA
  (application-directed access) protocols, the DB2/390 DRDA
  requester may terminate the connection to the server with sense
  code 08640000 even though no error in the Application Requester
  application is evident (no abnormal termination of the
  application). If this occurs, the server system may react in
  various ways but if the DRDA server is also DB2/390, then
  message DSNL500I with sense 08640000 may also appear at the
  DB2/390 Application Server.
  This problem occurs when a DB2/390 requester and the server
  are in session (SNA) with each other, and both are defined as
  capable of SNA two-phase commit protocols (for DB2/390 systems,
  this is defined in the VTAM APPL statement with
  SYNCLVL=SYNCPT).
  The problem occurs due to a combination of the fact that:
  1. The requester application connects to the server but
     then decides there is no need to send SQL to the server
     and terminates (deallocates).
  2. DB2 requester behavior changed to always allocate a
     conversation to the server (when the requester application
     Connects to the server) even if the requester decides NOT
     to actually send SQL to the server.
     This change in DB2 requester behavior was implemented in
     PQ03101 for V4.1 and PQ03130 for V5.1.
  3. SNA connections are used, as opposed to TCP/IP, and both
     partners support SNA two-phase commit (2PC) protocols.
  So the sequence of events to cause this condition is as
  follows:
    a. Connect to Server.
    b. SQL.
    c. Program ends, DB2 thread terminates and deallocates.
    d. Connect to Server
    e. Program ends, DB2 thread terminates and deallocates (note n
       SQL sent to server).
       Server site detects communication error.  If server is DB2/
       message DSNL500I 08640000 may be issued at server.
    Repeat a-e. Each time, step e will cause a DSNL500I at the ser
  So the condition occurs because the requester application
  connects to the server (thus the DB2/390 requester
  creates a conversation to the server), and terminates
  WITHOUT SENDING ANY SQL TO THE SERVER.
  
  When the DB2/390 requester thread terminates, it must
  terminate the connection to the server.  Since no data
  was actually sent to the server and since the connection is
  SNA 2PC, the DB2/390 requester must use deallocate ABNDUSER
  with sense code 08640000 in order to deallocate the
  conversation.  As a result, the server system will detect a
  communication failure.  If the server system is also DB2/390,
  the DB2/390 server may react by issuing a DSNL500I message
  with sense code 08640000.
  
  DB2 is working as designed. DB2 must physically create the
  conversation to the server (with PQ03101 or PQ03130) before it
  knows if the application really intends to send SQL to the
  server.  Because nothing was sent to the server and SNA 2PC is
  used, DB2 must terminate the connection with sense code
  08640000.
  Regardless of the fact that DB2/390 requesters behave this way,
  ultimately, it is an undesirable programming practice for
  requester applications to Connect to a server and then not
  bother to send SQL. If applications don't intend on sending
  SQL, they shouldn't bother to connect. There is a great deal
  of CPU and network cost associated with this in order to do
  nothing.
  DB2 requester applications should be modified to connect to
  the server only if they intend on sending SQL to the server
  otherwise the connection may have to be terminated by
  Deallocate ABNDUSER and sense code 08640000 which will
  effectively cause a communication error at the server (and if
  the server is DB2/390, this may result in a DSNL500I 08640000
  message).
  As a circumvention however, the user can use TCP/IP connections
  instead of SNA or the application can be changed so SQL will
  always be sent.
  *************************************************
  Additional symptoms and keywords:
    MSGDSNL500I DSNL500I
      SENSE08640000 SNS08640000 RC08640000 08640000
  

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