I haven't been able to reproduce the problem. I have set up a system as close to what they're using, given my hardware constraints. Table locking always catches the problem.

I do, however, understand what's happening to cause the duplicate cpimports. Looking at what they gave us, it is apparent that they are simultaneously running a similar colxml | cpimport pair for two different data bases at exactly the same time. They also use the same job number. This means colxml is writing to the same job file, so the second job (by lottery) is wiping out the first job file. Both cpimports are running against the same resultant job file; At the same time.

While they have different directories for the temp data for each job, the place where the job file itself is placed is determined by <WritEngine><BulkRoot> in the columnstore.xml.

They have now corrected the problem of using the same job number and the problem should not reoccur. However, it is still a mystery how they got past table locking.

The problem appears to be: in a separate UM/PM system, running concurrent colxml | cpimport jobs with the same job number.
One of the colsxml jobs will run first. The next will overwrite the first because the job filename is generated using the job number.
Next, both cpimport jobs will run against the same jobfile. In some cases (like at the customer's site), the table locking mechanism is circumvented and clashing occurs.

I haven't been able to reproduce the issue: table locking always catches the problem. Either there is some other factor I haven't figured out, or the timing must be different.