Re: Canonical list of QAQQINI options?

Ignore the options. They will almost surely be moot for the given situation. What transpired could have originated from something as simple as the existence of one additional row in a table or index for which the access plan [the chosen method\algorithms on how to retrieve the selected rows] is now different. The options will not enable nor disable any ability to bypass the rows with the bad data. Assume the origin for the errors was mere chance, and ridding of the failure would similarly be chance, even if by some manipulation of option(s). The only solution to avoid valid conditions of bad data is to pre-select only rows with good data [omit any selection which may refer to the bad data], or actually correct the bad data. The idea of "rolling back the cumulative" could be futile, as the origin for the change to the access plan is not necessarily only the code; and even if it helped, perhaps in some hours, days, or weeks later, the access plan may change back to the failing implementation for no obvious reason so begin failing again anyhow.

The message noted refers to named fields only, not unnamed expressions [even if there is a perception it were named; e.g. either as a "result field" name in Query/400 or using "AS" clause which merely gives the result a label]. Thus any "expression" which refers to the named column is likely the culprit; e.g. WHERE A/B=5 would fail for a reason code suggesting divide-by-zero when B=0, but could refer only to the column names A or B since there is only an expression, just as if\when SELECT A/B AS "AoverB" would know of only column names A or B since "AoverB" is merely a label rather than a column name or column number that can redirect to a column name. A pre-selection to avoid the error in the divide-by-zero case would be effected with a prior query that obtains only rows WHERE B<>0.

FWiW the new option noted appears by name and function to be intended to use only for a situation of a query gone horribly wrong, where the application of the existing RI or matching MQT is giving incorrect output... and thus would be used only to prevent the impact of such a defect; i.e. a circumvention, likely for a specific customer situation where an example of such a defect was found and is a serious impact for lack of any other acceptable circumvention [which would be either deleting some MQT or dropping some RI rules].

Regards, Chuck

Buck wrote:

I'm looking for a canonical list of QAQQINI options? I didn't
read all the cover letters of all the PTFs I loaded in the last
cume and I have an SQL problem I'd like to try to fix.

Background: I'm suffering from an SQL behaviour change after
applying cume 9104 to V5R4, and I have very few options. The
data has decimal data errors; it will continue to get decimal
data errors and it'll take months to nail all the holes. When
someone says 'legacy' in a pejorative manner, this is what they
mean. Anyway, I know I need to fix all of my application issues;
that's not SQL's fault.

What IS the fault of SQL is that my complex SQL SELECT with UNION
over the bad data used to work. Now it throws a CPF5033
(select/omit error - no useful info), SQL0802 (data conversion
error - no useful info) and CPD4019 (select/omit error -
unreadably useless information: wrong table name, non-existent
column number) Example message text: A select or omit error
occurred in record 0, record format *FIRST, member number 1 of
file XXXMST in library XXXXXXX, because of condition 6

Previously, the SELECT quietly returned all rows and posted no
errors. My problem is that my users can no longer use the inquiry
program because it no longer returns all the records.

It's all my fault, I know. I *ought* to have read every cover
letter of every PTF in the cume and I didn't. I'm sure this
behaviour change is documented in there somewhere, but I can't
locate it online.

My choices are few. I can roll back the cume, I can apply the
latest DB and HIPER groups or I can try to emulate the dynamic
SQL with native RPG I/O. Well, there's one more option - load
all the PTFs that mention CPF4019 et al.

Having learnt my lesson from the cume, I'm reading the cover
letters, which is lots of fun - the boss appreciates the work I'm
not getting done - and I come across this ditty in MF47206: ' A
new service QAQQINI option is provided to disable the MQT and RI
matching algorithm. QAQQINI option *SERVICE_AK should be set to
*YES to disable the RI matching algorithm.'

Great. A new QAQQINI option. And my wondering as to where I can
find these things documented, because the new options being
delivered by PTF aren't in the Infocentre.