CPF5035 used to be ignored, now causes SQL to fail

In our upgrade from V5R4 to 7.1, we've run into a situation where SQL seems to be acting differently. Granted, it's a problem with our data, but I'm trying to find out what our exposure is and whether there's a way to minimize the disruption.

The issue is that we are inserting from one table into another (an identically formatted work table). The problem is that in some of the records to be copied, a signed numeric field has blanks rather than zeros. On our V5R4 box, this completes successfully but on the 7.1 box it does not.

Using the exact same data and syntax in STRSQL, I see the following behavior:

In V5R4, I see multiple CPF5035 errors with what looks like an automatic reply of C. One is issued for every bad record, but the INSERT continues to completion and the inserted records show zero in the offending column.

In 7.1, I see a CPF5035 error for the first record with bad data, followed by two identical CPF5029 errors for the same record, followed by an SQL0406 (type 6 = invalid numeric data) which terminates the statement.

So, did IBM just tighten up the rules a bit on the INSERT? Is there a new setting somewhere that will allow me to ignore these CPF5035 entries? I don't have an entry in the system reply list for this message, and the message definitions for CPF5035 are identical on the two machines, so I've run out of ideas.

Joe