severe TERMINATE error on stored procedure

Anyone konw what this means, there are no other events in the log near this time frame.

2007-01-15-14.03.47.546651-360 I28945142G1048 LEVEL: Error
PID : 12117 TID : 3086001856 PROC : db2agent (PREFER)
INSTANCE: db2inst4 NODE : 000 Database : PREFER
APPHDL : 0-349 APPID: *LOCAL.db2inst4.070115195325
MESSAGE : Severe TERMINATE err at nest lvl 1, in SQL from rtn
DB2INST4.SS1_GET_LITTLE_X2:
DATA #1 : Hexdump, 136 bytes
0xB7645A20 : 5351 4C43 4120 2020 8800 0000 48FC FFFF SQLCA ....H...
0xB7645A30 : 0000 2020 2020 2020 2020 2020 2020 2020 ..
0xB7645A40 : 2020 2020 2020 2020 2020 2020 2020 2020
0xB7645A50 : 2020 2020 2020 2020 2020 2020 2020 2020
0xB7645A60 : 2020 2020 2020 2020 2020 2020 2020 2020
0xB7645A70 : 2020 2020 2020 2020 5351 4C52 4932 4331 SQLRI2C1
0xB7645A80 : 0300 0480 0300 0000 0000 0000 0000 0000 ................
0xB7645A90 : 0CFE FFFF 0000 0000 2020 2020 2020 2020 ........
0xB7645AA0 : 2020 2035 3730 3134 57014


The scenario:
script1.ksh calls script2.ksh
script2.ksh calls script3.ksh and runs it in the background (&)
script3.ksh calls DB2INST4.SS1_GET_LITTLE_X2 with the following statement:
db2 "call DB2INST4.SS1_GET_LITTLE_X2 ($INDEXID, $PARTID)" > /tmp/$$_build2b

The file /tmp/24697_build2b has the same timestamp as the error above with the following contents:
-rw-rw-r-- 1 db2inst4 db2grp1 72 Jan 15 14:03 24697_build2b
================================================== ==============
SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014

/var/log/messages shows a message 16 seconds earlier for that particular user disconnecting, but no other messages around that time.
Jan 15 14:03:31 predb24 remote(pam_unix)[23089]: session closed for user db2inst4

The user claims to have been kicked off his remote session a couple times during the day, but was sure he did not type a control sequence which I think was probably cntrl-c as he was connected via command prompt telnet. It is normal practice for the user to log off after the background process is running, but I do see this error happening inconsitantly now and again throughout the db2diag log in different stored procedures (but same scripts).

Any ideas?