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

APAR status

• Closed as canceled.

Error description

• 5740XYR00 HDB3310 HDB4410 HDB5510 HDB6610
  Also see Information APAR II09330, II11668.
  When using DB2 Distributed Data Facility (DDF) DRDA
  (application-directed access) protocols, the DB2/MVS DRDA
  requester may terminate the connection to the server with sense
  code 08640001 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/MVS, then
  message DSNL500I with sense 08640001 may also appear at the
  DB2/MVS Application Server.
  This problem occurs when a DB2/MVS 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/MVS 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 releases a    site (SITEA) by
     using SQL Release, or by using Type 1 Connect to connect
     to another site (SITEB), or by using Type 1 Connect or
     Type 1 Connect Reset to connect to the local site.
     As a result, every time the application needs to access the
     server (SITEA), it must first Connect (SQL Connect) to it.
  2. After the application connects to the server (SITEA),
     it decides there is no need to send SQL to the server so it
     commits.
     This is the key to the problem.
  3. 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.
  4. 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:
  . Case 1 (Type 1 connect)
    a. Connect to SITEB
       Note: SITEB could be local location in which case
             Connect Reset could also be used.
    b. SQL
    c. Static commit.
    d. Connect to remote SITEA.
    e. Static commit (note no SQL was sent to SITEA).
    f. Connect to SITEB.
       SITEA detects communication error. If SITEA is DB2/MVS,
       message DSNL500I 08640001 may be issued at SITEA.
       Note: SITEB could be local location in which case
             Connect Reset could also be used.
    g. SQL
    h. Static commit.
    i. Connect to remote SITEA.
    j. SQL
       Note: Need to send SQL so SITEA can reset indicator
             (LLMBFCNV) which allows the DSNL500I to be issued
             again next time at step f.
    k. Static commit.
    Repeat a-k. Each time, step f will cause a DSNL500I at SITEA.
    Note: This is a typical scenario for DPROPR APPLY
          applications.
          DPROPR has been requested to change their behavior
          with requirement REQ00072288.
  DPROR / APPLY has opened PQ52869 and PQ56427 to fix the msg.
  .
  . Case 2 (SQL Release - Type 1 or Type 2 Connect)
    a. Connect to SITEA.
    b. Release Current
    c. SQL
    d. Static commit.
    e. Connect to SITEA.
    f. Release Current
    g. Static commit (note no SQL was sent to SITEA).
       SITEA detects communication error. If SITEA is DB2/MVS,
       message DSNL500I 08640001 may be issued at SITEA.
    Repeat a-g. Each time, step g will cause a DSNL500I at SITEA.
  So the condition occurs because the requester application
  connects to the server, SITEA, (thus the DB2/MVS requester
  creates a conversation to SITEA), and releases the connection
  to SITEA WITHOUT SENDING ANY SQL TO THE SERVER, SITEA.
  
  When the DB2/MVS requester releases the remote site, it must
  terminate the connection to the server, SITEA.  Since no data
  was actually sent to SITEA and since the connection is
  SNA 2PC, the DB2/MVS requester must use deallocate ABNDUSER
  with sense code 08640001 in order to deallocate the
  conversation.  As a result, the server system will detect a
  communication failure. If the server system is also DB2/MVS,
  the DB2/MVS server may react by issuing a DSNL500I message
  with sense code 08640001.
  
  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
  08640001.
  Regardless of the fact that DB2/MVS 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 to
  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 08640001 which will
  effectively cause a communication error at the server (and if
  the server is DB2/MVS, this may result in a DSNL500I 08640001
  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
      SENSE08640001 SNS08640001 RC08640001 08640001
    DPROPR APPLY APLY
  

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