DSXchange

Tuning is, in my opinion, a two-phase iterative process. For some reason, many think that there are ready-made solutions to tuning, sort of like a magic "take two aspirins and call me in the morning", or "raise MFILES and all your problems will be gone". 1. Measure. The first ste...

Since a checksum by definition needs to traverse the complete file and that DataStage works on single rows and attempts to process them in parallel you won't have a builtin way of getting a checksum. But you can do an external call to UNIX to do this - the question is why do wish to do this? General...

What userid are you using and can you do a "touch test" or "mkdir test" in the target location from UNIX? Is the "UV.ACCOUNT" file there and what are the permissions on it?

Do you have other processes exclusively locking the table? Is there no SQL error code or text listed apart from what you posted? A DBA might be able to track issues from outside of DataStage as well.

Not line 8 but column 8, the "*" means a comment in column 7 and thus your error.

There has to be more error information, that is a pretty generic message - how does that lead you to assume contention?

I don't have access to DS or the manuals, but I kind of doubt your 1900000 addition/subtraction - that number looks wrong. Where did you get that and are you certain it works?

What solved the problem - renaming the table or using a different stage? You need to get back to where the problem is reproduceable in order to find out the cause by changing small things until the error goes away.

Have you tried the inverse function,

Could you post the exact error message(s) you getting - a lot will depend upon which type of contention you are seeing.

Can you break up the problem into 2 steps, first the ICONV and then the OCONV?
When you get "109096" what function do you use and do you convert it to a display date or a DataStage internal date?

When you put an output link from your target Oracle stage and enable rejects, the SQL error code is added automatically to the output link.

What column is that "*" in? Cobol is picky about indenting. Col 7 for comment, 8-11 and 12 to 79.

Just changing the name fixed it? Very odd indeed. Was the malloc() error caused by memory filling up? I suppose it is too late now to narrow down the cause.

Which OS are you using and could you post the volume settings? This speed difference might be due to sparse file allocation - OTOH, cacheing is done to speed up I/O and this might just be a case where it makes all the difference.