Bulk orchestrate import of table definitions

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

On the topic of the dsenv information, you're probably just missing the proper "source" syntax so that the contents come into your current script's environment. Typically it would be:

Code: Select all

cd $DSHOME
. ./dsenv
In other words you cd to where it lives and then "dot space dot slash" it.

As to orchdbutil, it's been four+ years since I've touched DataStage but I sure thought that was the command line utility to actually import the metadata rather than just generate it to standard out. Perhaps someone else can address this - how one would typically use it in this manner or if I should have sent you down a different path.
-craig

"You can never have too many knives" -- Logan Nine Fingers
rameshrr3
Premium Member
Premium Member
Posts: 609
Joined: Mon May 10, 2004 3:32 am
Location: BRENTWOOD, TN

Post by rameshrr3 »

Example syntax for orchdbutil in case you need it

Code: Select all

orchdbutil show owner.table_name -dbtype oracle -server Oracledb -dboptions {user=usr,password=***}
This will give you an orchestrate schema, which is handy ( actually its a parallel job table def )

Which version of datastage are you on ? IBM is already stating the old orchestrate operators used in Ora and DB2 enterprise stages are deprecated ( this was what orchestrate import was originally for) , and you are better off importing Connector table definitions, and connectors make it darn easier to import multiple tables in one go. Request your administrator to give you the 'Common Metadata Administrator ' Role in the IIS admin console , and you would be able to import the connector table definitions using Tools -> Import ->Start Connector Import Wizard.

Another reason to use Connector table defs is that they are automagically defined as shared table definitions, and would be really useful for metadata lineage analysis in Metadata workbench , In Fact IBM recommends using Connector table definitions over the orchestrate table import or for that matter the server job specific plugin metadata import.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

rameshrr3 wrote:Another reason to use Connector table defs is that they are automagically defined as shared table definitions...
Provided that such has been enabled as a General property for the project.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply