DSXchange

No, Eric means stop and start the agents. There is a script for doing this.

And, having checked, the added output column from the Checksum stage is of data type Char(32), so it's not 32 bits after all. So the odds are improved (the probability of a false positive is lowered) immensely.

Can you set up the worksheet as a linked table in MS Access and query it from there? This would be a useful diagnostic check.

Are there any other warnings in the log? Do you get any useful diagnostic information "from previous run..." after you reset the aborted job?

kaps wrote:Reading from a seq file and looking up to a hashed file and writing to a seq file.

Not really a parallel job, then?

Other than using a before-job or before-stage command to decrypt the file, I doubt it in version 7.

Your "no" is correct, unless you completely understand the layout of the Word file (tip: nobody does).

However, your DataStage might invoke some VBA script that performs that task as a before-job subroutine, so that the DataStage job itself can then process the text file.

Are you using COUNTRY_CODE in a stage variable or constraint expression?

Always check Fix Central to see what patches and fixes have been published. There are 20 in the Windows x86-64 list as of today, including a rollup Fix Pack 1 that has appeared with little or no fanfare.

Copying hashed files while they're being written to almost guarantees corruption. You need a better strategy.

No idea. They're nothing to do with DataStage or, indeed, any of the Information Server suite of products, which are what DSXchange exists to serve.

You can use an input text override, which may be preferable in this case.

No.

You don't get 16 values per bit, you get two. So it's 2 to the power 32. Divided by 2 because you're comparing two values.

If you can get 16 values per bit please get in touch offline - we can make a fortune!!!

Well, at least you're using an O/S from the TLA company.