RE: CPF5035 used to be ignored, now causes SQL to fail

When we first installed v6r1 on our system, we found the same stuff.

Basically, it seems to boil down to the SQL rules being more strictly en-forced. Each release does away with more and more of the Classic Query Engine...the newer SQL engine is more draconian with SQL rule enforcement and much, much better. I believe that V7R1 does away with the Classic engine altogether...so when we migrate to that OS version this summer, we are planning to encounter some of this type of issue all over again.

The better rule enforcement was viewed as helpful, but a pain in the a$$.

steve

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Wednesday, January 19, 2011 12:25 PM
To: Midrange Systems Technical Discussion
Subject: 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