Re: CPF5035 used to be ignored, now causes SQL to fail -- MIDRANGE-L

Joe,

There seems to be some PTFs that have been issued to fix some problems with
the same symptoms you are observing. Check this:

http://www-01.ibm.com/support/docview.wss?uid=nas2f92875ea69309d67862577cc003c9444

<http://www-01.ibm.com/support/docview.wss?uid=nas2f92875ea69309d67862577cc003c9444>

Also, there are some changes in the way that SQL treats decimal data. Now it
seems to be more "strict" in its handling of errors. A quick search give me
this:

(Memo to Users V6R1)

*Badly formed data can trigger data mapping error*
Prior to V6R1, if there was badly formed data in decimal or zoned fields
within physical files, it was
dependent on the query implementation and the interface as to whether an
SQL0406 or an SQL0802 data
mapping error would be signalled. In V6R1, there is better detection for
data mapping errors caused by
badly formed decimal and zoned data in non-SQL tables. It will be more
likely that an SQL0406 or
SQL0802 will be seen on V6R1. It will be necessary to correct the badly
formed data within the physical
file to avoid the data mapping error.
------------------------------
(Memo to Users i7.1)

*SQL Query changes in collation of errors might result in a SQL0802*

A change was made to not collate errors for SQL queries with ordering,
distinct, or aggregation. This was

done to avoid providing unpredictable or wrong results when a result in
error cannot be included in

ordering, aggregation, or distinct result sets. A selection error is now
signaled in this scenario, using the

SQL0802 message with SQLCODE=-802 and SQLSTATE=’22003’. The SQL0802 message
will be preceded

by CPF5035 and CPD4019 escape messages.

To allow compatibility with previous behavior, a new QAQQINI option,
COLLATE_ERRORS, is available.

COLLATE_ERRORS - Specifies how data errors are handled on the GROUP BY and
ORDER BY expression

during hash or sort processing within queries.

Supported values:

Chapter 2. IBM i operating system *15*

- *DEFAULT - The default is *NO.

- *NO - A value of *NO causes the query to be ended with an error when a
grouping or ordering

expression results in an error.

- *YES - A value of *YES indicates that the grouping or sort continues.

This support was also available by PTF in V5R4 and V6R1.

------------------------------

HTH,

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--

On Wed, Jan 19, 2011 at 1:55 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.