DSXchange

I haven't heard of this problem before. Is this limited to your client workstation - if so, then the patch probably caused the problem.

Parameters to a job cannot be changed once inside the job.

This has been asked several times before, check out this thread for some information.

crystal_pup wrote:...I have first created the required target file named ' Dept.fs' in UNIX in my home directory...

How did you do this?

If A and B are in the same schema, I would do it in the original SQL where you select your records. That would be the fastest, most efficient method.

Does your PATH environment variable contain that directory?

Are you using Server or PX to do this? You can ftp the files over first, then unzip them on Windows (this saves I/O overhead on the network); you could do this outside of DataStage in a script or within a job.

What is the average length of a record - could this error be happening on some typical power-of-two boundary? It probably won't solve it, but will help support get a handle on the cause.

After changing your partitioning methods you might not get much greater speed, but at least your data will be correct. What options are you using in the Oracle stage - particularly the load method.

Your error is being generated on the maths line, not on the string manupulation one. What is the value of Link1.incomingCol (including spaces) that you are failing on?

As Ray has already stated, that is odd. The at.exe command is in the Windows\System32 directory and that is part of the path in all installations. Could you check to see if it is there on your machine?

Considering the name of the site, there is a bit of a bias in here. Just as with most things, there is no absolute. Products such as Ab Initio and Informatica have their strengths, otherwise they would have gone the way of the dodo quite a while ago. Since there were very heavy ideological wars betw...

That sounds like the number to string math conversion used on Windows is not quad-precision. This certainly sounds like an error in DataStage that needs to be submitted to your support provider. Out of curiosity, does it work correctly if you explicitly code in a DecimalToString() call and peek that...

If you do the math, a 64bit pointer can address significantly more than 4Gb. Just call up your handy calculator and try 2^64. I never said that the OS won't allow 18Gb, that was your interpretation. Historically many OS's limited files to 2Gb, with the advent of 64bit addressing they allow files to ...

If you replace the PEEK with a sequential file output do you get the results you expect? If so, then the peek is doing the incorrect conversion.