对于我们的例子，假设该脚本在服务器端运行得很好，但是在客户端运行失败。由于该脚本不能在客户端运行，那么可以排除是应用层即 JDBC 到 DB2 CLI 接口的问题，因为 DB2 CLP 不经过应用层。另外还可以排除是服务器端的问题。
再次查看 图 1。可以看到，在应用层之下是 DB2 客户机和 DRDA 通信层。因此我们通过查看 DB2 和 DRDA 跟踪调查这两个层，看看网络延时如何。任何其他可能的问题应该由 DB2 技术支持来考察。
打开 DRDA 跟踪，找到带输入参数发送 CALL TEST_JAVASP(?) 的跟踪点。可以看到，对输入值的每次迭代对应于它自己的 DB2 跟踪点。在跟踪点 49130 处 FDODTA=9，在跟踪点 50460 处 FDODTA=10，最后，在跟踪点 51714 处 FDODTA=11。注意，在 DRDA 术语中，AR（Application Requestor）是客户机，而 AS（Application Server）是服务器。
清单 27. CALL TEST_JAVASP(9)的 DRDA 跟踪
49130 data DB2 UDB DRDA Communication Manager sqljcSend fnc (3.3.54.5.0.1177)
pid 2088 tid 2484 cpid 526 node 0 sec 223545 nsec 574400066 probe 1177
bytes 452
SEND(AR) OBJDSS - Object Data Stream Structure
LL: 35 CORR: 0003 CHAINED: y CONT ON ERR: n SAME CORR FOR NEXT DSS: n
NM: SQLSTT - SQL Statement
LL: 29 CP: 2414
DATA: (ASCII) (EBCDIC)
000000001343414C 4C20544553545F4A .....CALL TEST_J .......<<.....^[
4156415350283F29 FF AVASP(?）。 ....&....
...
...
SEND(AR) OBJDSS - Object Data Stream Structure
LL: 36 CORR: 0004 CHAINED: n CONT ON ERR: n SAME CORR FOR NEXT DSS: n
NM: SQLDTA - SQL Program Variable Data
LL: 30 CP: 2412
NM: FDODSC - FD:OCA Data Descriptor
LL: 16 CP: 0010
N-GDA Len: 06 Type: 76 ID: D0
Var[00] Type: 0X03 Len: 0X0004
Footer: Length: 6
DATA: (ASCII) (EBCDIC)
0671E4D00001 .q.... ..U}..
NM: FDODTA - FD:OCA Data
LL: 10 CP: 147A
DATA: (ASCII) (EBCDIC)
000009000000 ...... ......