DSXchange

I know, but stated is stated and it seems like all the who-ha one would normally have in the dsenv file is instead in the user's .profile. Or as well. [shrug]

Start here and say "Thank you Vincent!" :D

http://blogs.ittoolbox.com/bi/websphere ... -past-8819

arun_kumar wrote:In my datastage server there is no dsenv file.

Let's not forget this statement in the original post.

Really? Huh... for some reason I thought that was per hashed file. And 'all' means all cached hashed files per active process?

Never could find in the docs where it explicitly stated, one way or the other, exactly what the setting was.

Sorry, but I can't really speak to a .bat file solution except in generic terms. Scripts should be as robust as possible. Assume nothing. Check as much of the output as you possibly can. From a UNIX standpoint, at the very least we capture the $? status and alarm when that is non-zero. For ftp, whic...

Welcome aboard. :D

That error simply means that at least one of the columns you've included in the stage does not exist in the target table. In this case, one called 'COL1'.

Out of curiousity - what operating system? And was this a 'root' install?

I/OConv would handle all of those concerns automagically. Are they not available in PX jobs?

It's got to be about granting those rights to the user you are connecting as rather than to any particular stage. Talk to your Netezza DBA.

You need to verify that you are actually passing the warning limit correctly to the job run. Echo out the complete dsjob command just before you actually execute it and capture that somewhere. The documentation says in many places: By default a controlled job inherits any row or warning limits from ...

They are typically one very long line and thus not at all suitable for the FTP Stage. Stick with a scripted solution.

If I tick the create fiel option for each run , so DS creates the hash file for each run or just overites the existing file? Checking the 'Create' option just gives you the opportunity to override the default creation values. The only way those get applied 'each run' is if you also enable the 'Dele...

At this point, suggest you call your Support provider.

If your quotes were always coming in around the DATE parameter's value, that would explain why it continued to complain about a 'bad value'. I would assume they came from the flat file you sourced from - quoted string there but brought in whole by your 'read'. So the answer all along may have been t...

What arguments? Of course they are supported.