II14004: DSNL027I ABEND04E RC00E50013

APAR status

• INTRAN

Error description

• Key words: 5740XYR00 RC00E50013 MSGDSNL027I DSNLILOS
  .
  Soft cancel in the distributed job recorded in DSNL027I and
  DSNL028I w/ ABEND04E RC00E50013 .
  .
  From erep logrec software detail report SDWA key xDD we can find
  ebcan14 and ebocan14 address, for example:
  +012    KEY: DD     LENGTH: 20
  +014    00000007    93C14086    00000000    8FFFA490    |....LA
  +024    0F93E798 ++ 93CC8B74 ++ 93CC8B74    00000000    |.LXQL..
  Use x93CC8B74 to research in MEPL for the ddf module and it
  normally is from DSNLILOS detecting the session loss from client
  deallocation.
  .
  Or you can set a slip to capture a dump and format EB (Reg 6) to
  get the ebcan14 and ebocan14 addresses for the issuing module.
  SLIP SET,ACTION=SVCD,COMP=04E,DATA=(15R,EQ,00E50013),
  ID=xxxx,JL=(db2subsys*),ML=5,
  SDATA=(ALLNUC,CSA,PSA,RGN,SQA,SWA,LSQA,GRSQ,TRT,SUM,XESDATA),END
  .
  To determine if the session is deallocated from client, we would
  need the following pieces of information to review.
  From zOS site:
  1) a) TCPIP Packet trace with no wrap and sufficient allocation
  of the buffer. DO NOT USE ANY FILTERING ON THE PACKET TRACE. See
  II12014 for details on collecting a TCP/IP Packet Trace.
  b) Identify the client and server IP addresses (IPADDR) and PORT
  (PORT) numbers.
  c) Format the TCP/IP Packet Trace using IPCS CTRACE commands.
  We can request support from TCP/IP in Raleigh to assist us if we
  like. It may be useful to filter the raw packet trace using the
  known client or server IPADDR or PORT number.
  d) We need to find out from the formatted packet trace, where
  the TCP/IP FIN command originated from. To do this, search for
  the ACK FIN flags. If FIN command is found in the 'FROM
  INTERFACE' packet trace, then this indicates the client
  connection is the originator of the FIN command. In this case,
  contact the supporting team for the client connection side for
  further investigation.
  .
  2) SLIP DUMP for rc00e50013
  3) SYSLOG and LOGREC detail report for the timeframe
  From UDB client site:
  1) DB2 Trace with FMT or FMTC (ddcs -c option) format file for
  DRDA buffer flows.
  2) JCC/CLI trace depending on using the TYPE4 JDBC driver or not
  .
  The following are known situations with the rc00e50013 in DDF
  issued from DSNLILOS:
  1) UDB DB2 CONNECT client and server via TCPIP to zOS:
  PMR Examples: 76286,344 92640,227
  UDB DIAG.LOG recorded sql30081n communication error on Gateway:
  DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
   sqlcaid : SQLCA     sqlcabc: 136   sqlcode: -30081   sqlerrml:
   sqlerrmc: * * 0 TCP/IP SOCKETS 129.219.79.197 recv
   sqlerrp : SQLJCMN
  sqlerrd : (1) 0x81360012      (2) 0x00000012      (3) 0x00000000
            (4) 0x00000000      (5) 0x00000000      (6) 0x0000000
  sqlwarn : (1)      (2)      (3)      (4)        (5)       (6)
            (7)      (8)      (9)      (10)       (11)
  sqlstate:
  .
  On the client site DIAG.LOG would have more errors.
  This is due to the old client udb version/fixpak while the gatew
  gateway is at newer UDB v81 fixpak case. UDB support suggested
  upgrade both client and server to current version/fixpak, ie.
  UDB v81 or V82 with current fixpak. Or, Client should be at
  least at UDB v7.2 fixpak 13 and server should be at udb v81
  fixpak 8.
  .
  2) Client is at current UDB v81 fixpak. Client diag.log recorded
  sql30081n with rc54 informing host (zOS) is deallocating the
  session.
  PMR Example: 80879,300,624
  TCP Packet trace revealed ACK PSH FIN is from source of zOS port
  Normally when DSNLILOS detects the session loss, that means the
  client sends us 0 length data to indicate the session
  deallocation. In this case, there is a timing window between the
  cancel thread process and DSNLILOS detecting the session loss.
  The fix on zOS is
  PQ93454 / UQ93138 (db2 v71 put0410) and UQ93139 (db2 v81).
  .
  3) JCC TYPE4 Universal Driver getting timeout resulting in
  RC00E50013.
  PMR Example:  16803,487 -> 30567,487
  Client JCC TYPE4 Driver received communication error in sqlcode
  -4499 ( sqlcode4499 sql4499 sql4499n ). zOS DB2 server site
  resulted in ABEND04E RC00E50013 for soft abend issued from
  DSNLILOS.
  TCP Packet trace revealed that the ACK FIN is coming from source
  client port to deallocate the session. This is due to the ill
  defined "loginTimeout value" on the JCC03000 client.
  That the unexpected close of the socket occurs because JCC
  client has a login Timeout value that is too small.
  .
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

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