When running LOAD with CPU_PARALLELISM > 1 (and when "modified
by anyorder" option is not used explicitly or implicitly), LOAD
ridder thread emits SQL3227W messages to map tokens such as
"F6-1368" to row number.
When WARNINGCOUNT option is used, LOAD should stop processing as
soon as WARNINGCOUNT limit is reached, and for technical reasons
LOAD ridder can no longer keep track of row number accurately
after WARNINGCOUNT limit is first reached. However, because
LOAD runs multiple formatter threads asynchronously when
CPU_PARALLELISM > 1, after the first formatter thread hits
WARNINGCOUNT limit (and LOAD begins to terminate), other
formatter threads may also hit WARNINGCOUNT limit before they
receive notification to terminate, and they emit warning
messages that cause ridder thread to emit SQL3227W messages, and
these SQL3227W messages (after the one at the time when
WARNINCOUNT limit is first hit) may contain incorrect row
number.
This fix is to make LOAD stop emitting SQL3227W messages after
we hit WARNINCOUNT limit the first time, thus avoid giving
SQL3227W messages with incorrect row numbers.
Secondly, if dumpfile option is used, then we also stop any
subsequent formatter threads that hit WARNINGCOUNT limit (after
the first formatter that hit it) from writing the
row-that-caused-warning into the dumpfile, thus the dumpfile
will only contain one row that is written due to hitting
WARNINGCOUNT limit. |
