DB2 JDBC addBatch truncates DECIMAL fields during inserts, if the last row has null values

[bunty.gopal]

I am trying to use the PreparedStateme nt's addBatch to load data in an
ETL-like process into a table. There is a single prepared statement.
The parameters are set on it and prepStmt.addBat ch() is called. Then
the next iteration of setting the params and adding to batch begins.
Finally after setting the batch of 2 to 2000 rows, the
prepStmt.execut eBatch() is called.

If the last row contains a null value for a particular DECIMAL field,
then the value for that field in all the rows is stored truncated to
their integer value in the table. Tried using different methods of
setting the null - setNull, setObject, setBigDecimal etc, but still the
value is truncated. If the DECIMAL fields in the last row are not null,
then this truncation does not happen. Note that it only happens for
those DECIMAL columns, that have a null value in the last row.

E.g.:
statement:

INSERT INTO PAY (EMP_ID, AMT_PAID) VALUES (?, ?);EMP_ID is INTEGER
AMT_PAID is DECIMAL(12,4)
If the parameters were set as follows, in the same order:

EMP_ID, AMT_PAID
----------------
1001, 3414.5512
1002, null
1003, 3151.6633

Then there is no truncation.
But if the parameters were set in this order:

EMP_ID, AMT_PAID
----------------
1001, 3414.55
121003, 3151.6633
1002, null

Then, the values of AMT_PAID get truncated in all rows. i.e. in DB, it
appears as:

EMP_ID, AMT_PAID
----------------
1001, 3414.0000
1003, 3151.0000
1002, null
All decimal values are stored using setBigDecimal. Integer values are
stored using setInt. All methods of setting the null were tried -
setNull, setObject, setBigDecimal etc. but with same error. I debugged,
and found that until the executeBatch is called, the value contained in
PS is proper, but the value appears truncated in DB. :(

Is there something wrong being done? Is this a known issue? Any
workarounds or patches?

The JDBC driver files are from the db2_jdbc_t4.zip available from IBM's
website. DB2 version: DB2/6000 8.1.6.

Thanks,
Gopal