DSXchange

the values of "01 00 & Q 00 80" do not look like a valid COMP-3 field value, regardless of whether it has a leadin or trailing sign. Are you certain that you haven't done an EBCDIC to ASCII conversion here?

Yes, you can. Various methods are available including Join, Funnel (for like records), Combine records, Lookup.

Does the error occur when running the job from the director, in other words is it related directly to the "dsrun" command call?

You can use RCP to take care of the different metadata used by or given to the shared container by different jobs.

I would try making a copy of the job, deleting the original, renamin & recompiling the copy and seeing if the error persists, it might be some problem with the log file used by the director.

Oracle type 12 (see the DUMP command) is date, you are supplying a string. Use StringToDate() to convert your string to a date type.

So that would cancel out a problem with some 12-hour overflow occuring, it is just a timing event. The millisecond values retrieved from some UNIX variants aren't always that accurate, so it might just be a cross-process timing issue - which explains why this is a warning and not a fatal error. I se...

Did you create "hsh_Staging_3" as a local file in the project or as a pathed file. If the latter, you will need to make a local file pointer to that file. The "SETFILE" command will do this for you, for instance "SETFILE SETFILE PathToYourHashedFile TempHashedFile" then...

Good luck getting that from IBM. That information might not be quite as well protected as the formula for Coca-Cola, but it certainly won't be made available to anyone not in IBM and not needing that information to do their job

From the TCL command line or from your admin, execute "RESIZE YourHashedFile DYNAMIC 64BIT"

Either FTP the .dsx to your server, or use the "dscmdimport.exe" program on your client.

After how long does this error message occur, before or after the first 12 hours?

You could try using unbounded VarChar() fields in the lookup and use only those columns you need to reduce lookup size. If that fails, you will need to revert to a JOIN stage.

"Hint"? It looks like the millisecond values aren't being returned correctly in this one case, or does this error refer to 2 entries spaced (just a bit more than) 12 hours apart?

Just grasping at straws, since the problem is not obvious from the data provided. If you copy a 7.5.2 job and recompile it, does it run? If not, then edit the job, delete the Teradata stage, save the job, re-edit and insert a new Teradata stage. Does the job now compile and run?