DSXchange

The easiest way is to run a shell script which runs sqlplus or whatever.

It does not matter if dsenv is a Korn shell or a Bourne shell. PWD is dynamically set in ksh. A DataStage job is not a Korn shell. It may execute a shell but it's current directory is the project directory. So you could fake it out. I doubt if any Korn shell will let you set PWD. If you need this va...

This still should not happen on a regular basis. If people are in the Designer and have a job pulled up and walk away from their PC then tell them not to. Always leave no jobs up in Designer when you walk away from your PC. This is easy to do. If you develop good work habits then these issues go away.

If you are talking about size limit then it is based on several things. In UNIX it could be 2GB unless you use the 64 bit option. It could also be the ulimit. It could be the filesystem size. The OS makes this decision most of the time. Different versions of UNIX treat this differently. There are lo...

PWD is a Korn shell concept. It is not available when a DataStage client logs in or a job runs as a phantom.

I really do not like to have multiple links one for OK and another for warnings. By the way we use Ds7.1 and abort goes through the exception handler. I think the way this works it is cleaner to use aborts.

Thanks Ray. That is my point. An abort is not the same as kill -9. The process dies gracefully.

You need to fix your PATH or the dsjob command should be so full path. The dsjob command is in DSEngine/bin. I fixed my version by making the dsjob parameter default to ../../DSEngine/bin/dsjob -report.

For some reason that project is messed up. I would call ASCL support.

DSStopJob has been around for awhile besides what is the difference between DSStopJob and aborting a job.

We do it all the time. Sequences can trap aborts easier than warnings. Aborts will go through the exception handler and warnings do not.

That is correct.

That is why you are corrupting indexes. Teach your developers to logout of DataStage when they leave their desk.

You can make this a user defined query and use the parameter in a where clause like select from where UPDATE_TS > to_date('#StartDate#') You can calculate this date in the job before this. You will need to store this date in a hash file or sequential file and read it back to feed it into this job. Y...

I would make sure all the files are owned by the same group. Do a chown. Make sure your umask is set in dsenv and in the uv.rc in the start up script.