JR30369: JCC TYPE 4 CONNECTION HANGS WHEN GOING TO A DB2 CONNECT TO A ISERIES (V6R1)

DB2 Version 9.5 Fix Pack 3b for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

APAR status

• Closed as fixed if next.

Error description

• The problem is best seen by looking at the trace file
  fmtAsClient.fmt. At connect time, the JCC client sent the ACCRDB
  request with TYPDEFNAM = QTDSQLASC. It received the ACCRDBRM
  from the gateway with TYPDEFNAM = QTDSQLX86. Later, at trace
  record 3447, gateway got the PRPSQLSTT + OPNQRY request, sent it
  to iSeries, go the reply at 3627 and sent the reply back to JCC
  at 4052, but it also inserted TYPDEFNAM = QTDSQL400 before
  QRYDSC. This is normal if the gateway is a Windows machine.
  
  The problem here is that JCC remembered the last TYPDEFNAM of
  QTDSQL400 and applied it to the next reply for the subsequent
  CNTQRY request. That next reply was only an SQLCARD, but the
  TYPDEFNAM = QTDSQL400 was only in effect for the life of the
  reply in which it was flown. The separate reply containing only
  SQLCARD (see trace point 4418 where gateway sends it to JCC)
  didn't have any TYPDEFNAM, so the TYPDEFNAM to be applied is the
  one negotiated at connect time, i.e. the one flown by the
  gateway to JCC in ACCRDBRM (TYPDEFNAM = QTDSQLX86). The sqlcode
  in the SQLCARD at 4418 is byte-reversed , which is correct for
  TYPDEFNAM = QTDSQLX86 (little endian). JCC needs to convert this
  sqlcode to big endian because it connected using TYPDEFNAM =
  QTDSQLASC.
  

Local fix

• Avoid using DB2 Connect server. Connect directly to DB2 for i
  server.
  

Problem summary

• JCC type 4 connection will hang if you go from DB2 Connect to a
  I-Series <V6R1> Will be first fixed in v9.5 fp3
  

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:

  JR30427

Fix information

Applicable component levels

• R950 PSY

     UP