DSXchange

Command line executable.

It's not a workaround, per se, but yes - Project level stores the default value applicable only to new jobs. Changes to existing jobs need to be done at the individual job level.

Out of curiousity... 'retrieve' in what sense? Rebuild / reverse engineer?

Hmmm... that's more for Server, for PX you should be using orchdbutil from what I understand.

So, they are actually NUMBER(15) fields in Oracle? What are you using to do the metadata import?

Not that I am aware of, but perhaps someone else knows a way. So, you need to do more than, say, create a .csv data file that someone could then open in Excel, yes?

You would have to write a batch file to call your command line query tool of choice and then use ExecDOS directly or DSExecute in a routine to execute it. ... That's what I've done now. However the batch file always returns a positive result since even if the SQL query fails as far as DOS is concer...

Are you able / willing to try a 9.2.0.1 version of the client on AIX as well?

No. You can reinstall DataStage but without backups of any kind, all of your work (the jobs, etc) is gone. Someone needs to be shot. A couple of someones, it seems.

You would have to write a batch file to call your command line query tool of choice and then use ExecDOS directly or DSExecute in a routine to execute it.

Macro? What kind of 'macro'... an Excel macro?

DataStage does not have a "scheduler" built in but rather leverages whatever the O/S provides. For Windows that would be "at", for UNIX both "cron" and "at".

In that version, pretty much all you can do is export both to .dsx files and then use something like UltraCompare to diff them. From what I understand, in later (8.x) versions the 'diff' is built into the GUI.

How is this question any different than your other 'performance' issue? Talk to your Sybase DBA about bulk loading options.

As suggested earlier, IsValid() should be another choice.