CPF5035 used to be ignored, now causes SQL to fail

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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