× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.