DSXchange

This should be reported to IBM as a bug, the fix should be quite easy as it just seems to be a bad datatype definition.

I've managed to solve the problem posted and it wasn't quite as onerous as I'd expected. The solution is to use a generic stage and use the parameter value in the statement there. 1. Write the output to the DB stage (whichever one you choose) using RCP but explicitly declaring the key column in an u...

No major changes at all that I can think of, the main advantage would be any bug fixes in the new version.

Trim(In.Column,'-') will remove dashes.

I thought that rather strange, but wrote a test program on my machine and it does seem as if they've limited the maximum output of PadString to the maximum length of the input string.

In your case "In.FLAT:Spaces(40-Len(In.FLAT))" will work instead.

After posting my question I have thought a bit more about the problem. In kwwilliams method I would need to store the record columns somewhere and pass them to the job, not a task I'd like to perform. I think that I might be able to do this using the generic stage and issuing the keys explicitly and...

One way to change all new dynamic files to 64bit is to set "64BIT_FILES" in the config file. This is a very bad idea and I recommend not doing this, since ALL new files will be 64bit and have an increase in storage and decrease in performance. From the UV command line you can do a RESIZE {...

Could you turn on "$APT_PRINT_SCHEMAS" and see if the displayed internal schemas differ between the two users and post any differences to the thread?

I'm writing a generic job that takes a table name and key column name as input parameters. The tables to process all have different key column names. The job reads a table, performs some processing and then should write the updated record back to the table. I can get this job to function correctly w...

But I am certain that the extra 8000 entries in the director are instances, which are stored in the single log file for that job and don't impact performance, apart from the size of the log file.

Hard to say exactly. Was the actual directory created? What are the access rights on the other projects on your system?

Yes, it is possible to do so.

It does sound like a bug/problem in the SCD stage (since the error disappears when you remove the stage). If you replace your ODBC output with a PEEK or sequential file stage does the error persist?

See if setting APT_DISABLE_COMBINATION to "true" changes the error message, perhaps it was incorrectly reported.

Do you have unusual data types in the record?

Is this the read or the write stage? Are you doing any SQL? How many rows of data or megabytes of data in the file and how long before the failure occurs after starting the job? If this is the read stage, then make a copy of your job with just the Read and a peek stage and see if the problem persists.