DSXchange

You've now established that the bottleneck is FTP and not the subsequent processing.

How long does it take to FTP the file from the command line?

The bulletin board system messed up your formatting (I believe if you use quote or code tags that won't happen). Take the steps one-by-one. - What is your join key on the first join? You want to make sure that your incoming left and right link data is partitioned and sorted on the join key(s). If yo...

I would first ensure that the FTP is indeed the bottleneck in this case. If you make a copy of your job and go straight from your FTP stage to a peek does the job still take 70 minutes?

I usually end a up making a copy of the job, then progressively delete columns until the error goes away and hopefully having written down the last deletion so that I know which column is at fault.

What is your target date datatype and database?

In this case multi-instance jobs play no role.

If you can do it in a modify stage, then you can do it in a transform stage. Is the column name in question a known one or are you passing the name in as a parameter?

I don't know what the problem cause is, but really dislike those non-deterministic type of errors!

- Is this a multi-instance job?

- Is the server under a heavy load while this is happens? And is the load less when the operators restart the job and it runs successfully?

I have to admit that I use the modify stage less and less over time. There is no reason not to use a transform stage and the CONVERT() function to solve this problem.

Going backwards has never been supported, but usually worked when jobs didn't use features not present in the earlier version. Backwards compatibility has always worked and been supported; we could probably load V5 and earlier server jobs on 8.7 and they would work. It does look like we've reached a...

I have seen the problem demonstrated again today, with the same client and the same settings (refresh rate in the director) everything works as expected on one 8.7 machine but on the other, which I believe was installed with the same response file as the first machine, the director doesn't reflect t...

No, I don't have a foolproof method and will keep your problems in mind next time I need to retrograde a job from 8.7 downwards. I had always assumed that if the job was imported it would work but that seems to no longer be true.

The conversion for VarChar() to integer is implicit and doesn't need to be explicitly programmed through a function. If the VarChar() contains values that aren't convertable to integer then you should use an "IsValue('int32',Input.Column)" to ensure that no values are dropped or warnings a...

Did you import the whole project or just the one job and corrupted the project? I've retro-imported jobs several times and as long as they didn't use functionality not available in the version to which I imported the jobs they worked fine (although often I'd get warnings during the import process). ...

What is the display format use by your web service? You should convert your timestamp data type to a string within datastage using that display format so that the webapp can parse it.

SURA, just as a side note, I wouldn't hold my breath until this APAR makes it into a production release. I'm certain there are a couple of open enhancement request APARs in the system that I submitted.. before the year 2000 :) Enhancement requests are tough, if the marketing folks don't see a benefi...

Oddly enough, I've been seeing this problem since yesterday on one of the 8.7 machines here. Whe I manually do a "refresh" in the Director the correct state is displayed. But if I don't, the job status is "not compiled" but the director merrily refreshes the state of other runnin...