DSXchange

I'm not in a position where I can check , but I think that the custom SQL value is stored inside the job, thus you are seeing a previous entry. I think if you were to start with a 'clean' stage where you haven't toggled the values before then you won't see that error.

I went from 8.0x to 8.1 on AIX and we had to convert our buildops from the 32bit to the 64 compiler/linker

You can declare a transform stage output link as "rejects" which triggers a warning in the log, so if you redirect your truncated string records using a constraint you will get warnings in your log. This would be easier than calling the c++ equivalent of DSLogWarn() through a custom buildo...

Yes, at 8.1, as Ray has stated.

Why are you making this so complicated; the leap year logic is built into the DataStage date processing, so (as mentioned earlier), add one month to your date and then subtract a day and -voila- DataStage gives you a correct date, every time.

The only normal method of getting data from a host to a server is via FTP or a derivative (i.e. connect:direct or FLAM or the like). If you don't want to land the data on the UNIX machine you could use the DataStage FTP stage to read the data line-by-line and process it; but then you would need to b...

It is a simple "ls" command, but if the drive is not mounted or not accessible at runtime the error message might assist in finding out the cause of your problem.

You cannot demote message types in Server jobs, this functionality exists only in parallel jobs. Ray already provided an answer:

Ray.Wurlod wrote: Not possible if you have a reject link.

Oops

How is this drive mounted? Is it mounted per session or at a system level and is available to all users? You can try to add a before-job UNIX call and execute 'ls -al /mnt/edw/infosys/EBI_Work/' to see if that directory is available and what the access rights to it are, as seen by the DataStage runt...

Since scheduled jobs usually get started by another userid any differences between normal and scheduled runs are usually explained by access right or environment setting differences. While these error are usually not SIGSEGV ones, it is still worth checking. Also what is at line 25 of your project /...

You could do a job level message handler and demote the warning messages generated from the database rejects.

Try to change the query to a fixed one temporarily, i.e. "SELECT COUNT(*) FROM Your.Table" and I'd wager your error persists. Are you certain you are passing instance/user/password information correctly into the stage?

It looks like the routine is not catalogued. If you go to your designer and look at the sdk routines you should be able to find it - perhaps it is miss-spelled in the job?

Look at both sequential files stages and ensure that the properties tab for 'reject mode' is 'output'.