DSXchange

But in short you cannot export 1 job via the command line. You can export all jobs and then cut out the job you need (several 3rd party little tools exist to do that).

Maybe a little off-topic... did anyone ever find out how many companies are using DataStage worldwide. It would be interesting to know, I anyway would be interested in it.

Regards,
Ogmios

It's a DB2 thing, not a DataStage thing. Talk to your DBA's :D

In practice we reboot... Considering your response and sig, what do you do in theory. :D LOL :D in theory it remains up for ever. In practice you see in DataStage v7.5.1 on a Solaris server that after 3 a 4 months sometimes jobs won't start properly anymore (you get the starting lines in the log fi...

In practice we reboot DataStage v7.5 about every 3 a 4 months... at that time datastage starts to become erratic and won't start up some jobs anymore.

koolnitz wrote:Thanks stefanfrost1 for your response.
Is it a limitation of DB2 API stage or it is supposed to behave this way?

It's supposed to behave like that... runstats is not SQL. It's similar to Oracle and SQL*Plus, you can execute things in SQL*Plus which will throw errors at you in the Oracle Stage.

ssunda6 wrote:Yes. The data is same.

If all else is the same, I would have your DBAs import the stats from the one database into the other.

Is the data being processed the same on both servers?

Easiest way out... schedule your job the normal way via the DataStage gui's. Then look at what DataStage puts into the scheduler, if you put that in TWS it will work. On Unix it works the same with crontab. If you even want to go a step further you can make sure that DataStage first sees your own &q...

3113 is the dreaded Oracle error message... it means the oracle server process killed itself prematurely. Raise an incident log with Oracle, if you look in the alert.log of your database you may find some other clues. 3113 basically means the Oracle process ended in an abnormal way and usually requi...

And while you're at it :D try out Talend ( http://www.talend.com ) and Kettle ( http://kettle.pentaho.org ), open source ETL tools. They're going to get away with a big chunk of DataStage/Informatica/OWB market share in a year to a couple of years. The bigger bucks are going to be in the architectur...

It's not a DataStage problem, it's Oracle and it's not a problem. In Oracle when you update the same row at the same time from different sessions you block each other. In order to use parallellism the right way you have to make sure that you divide up rows and that no 2 sessions try to update the sa...

my mistake... the passwords are not encrypted. They are all unencrypted in a file which can only be accessed by 2 people because of OS permissions. They are also unencrypted written to a small temp file which is then used by dsjob so that the password doesn't appear on the command line (via ps -ef) ...

What we did is that the scheduler account is secure with only 2 people having access, the passwords are stored in a file which is chmod 700. This file is sourced in (unencrypted passwords) and in the past the variables were used to pass to dsjob. But then you could see the password in "ps -ef&q...

my hunch would be that you have access rights problems in your project directory. Are you using the same userid now as you were using before? In any case, a schedule for a job (when done from the GUI and not with dsjob) consists of 2 pieces: some small piece in your project itself and the part in th...