DataStage question.
We need to have 2 instances of Oracle on a Sun box which is also running DataStage at the same time.
On this box we have two projects each of which will connect to the respective Oracle instance. Each project should be completely isolated from the other, apart from the DataStage server engine. (When are we going to be able to run multiple instances of UV?)
Given the the DataStage server engine/unirpc is started with the S99uv.rc script which in turn calls dsenv, which sets up the oracle environment variables etc. How can we change these depending on which project the client connects to.
Regards,
Phil.
Two environments of one machine (QA and DEV)
Hi Phil,
Were managing this by setting up all of the connection information via job
parameters, then in UNIX we call the jobs from the UNIX command line. The
move to QA or production requires us to change the parameters within the shell script when we move to QA. (We have a routine to do this once and set and use that parameter in all the subsequent datastage jobs.)
Example:-------------------------------------
JOB Params:
oracle_owner: dev
oracle_tns: tns_dev
app_path: /dev
---------------------------------------------
UNIX DEV script:
oracle_owner=dev
oracle_tns=tns_dev
app_path=/dev
#job1
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
#the dsParamString is the list of params and paramvalues
...
# call datastage command line
/opt/ardent/uv/bin/dsjob -server $host -user $dsuserid -password $dspassword -run -mode $dsmode -rows $dsrows -wait -jobstatus $dsParamString $dsproject $dsjobname 1>> $log_file 2>&1
---------------------------------------------
UNIX Qa script:
oracle_owner=qa
oracle_tns=tns_qa
app_path=/qa
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
# call datastage command line
...
---------------------------------------------
Its not automatic, the UNIX scripts have to be modified (3 lines per script), but not anything in the jobs. The UNIX params overlay the job parameters (as long as you specify the param name exactly) when you run the job. (p.s. disclaimer - I did edit this after cut and past, so this is not actual executable code).
Good Luck,
Katherine Lapic, Data Architect, katherine.lapic@genmills.com Enterprise Data Management, General Mills
-----Original Message-----
From: Phil Walker [mailto:philw@gnosys.co.nz]
Sent: Thursday, January 04, 2001 7:40 PM
To: informix-datastage@oliver.com
Subject: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
DataStage question.
We need to have 2 instances of Oracle on a Sun box which is also running DataStage at the same time.
On this box we have two projects each of which will connect to the respective Oracle instance. Each project should be completely isolated from the other, apart from the DataStage server engine. (When are we going to be able to run multiple instances of UV?)
Given the the DataStage server engine/unirpc is started with the S99uv.rc script which in turn calls dsenv, which sets up the oracle environment variables etc. How can we change these depending on which project the client connects to.
Regards,
Phil.
Were managing this by setting up all of the connection information via job
parameters, then in UNIX we call the jobs from the UNIX command line. The
move to QA or production requires us to change the parameters within the shell script when we move to QA. (We have a routine to do this once and set and use that parameter in all the subsequent datastage jobs.)
Example:-------------------------------------
JOB Params:
oracle_owner: dev
oracle_tns: tns_dev
app_path: /dev
---------------------------------------------
UNIX DEV script:
oracle_owner=dev
oracle_tns=tns_dev
app_path=/dev
#job1
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
#the dsParamString is the list of params and paramvalues
...
# call datastage command line
/opt/ardent/uv/bin/dsjob -server $host -user $dsuserid -password $dspassword -run -mode $dsmode -rows $dsrows -wait -jobstatus $dsParamString $dsproject $dsjobname 1>> $log_file 2>&1
---------------------------------------------
UNIX Qa script:
oracle_owner=qa
oracle_tns=tns_qa
app_path=/qa
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
# call datastage command line
...
---------------------------------------------
Its not automatic, the UNIX scripts have to be modified (3 lines per script), but not anything in the jobs. The UNIX params overlay the job parameters (as long as you specify the param name exactly) when you run the job. (p.s. disclaimer - I did edit this after cut and past, so this is not actual executable code).
Good Luck,
Katherine Lapic, Data Architect, katherine.lapic@genmills.com Enterprise Data Management, General Mills
-----Original Message-----
From: Phil Walker [mailto:philw@gnosys.co.nz]
Sent: Thursday, January 04, 2001 7:40 PM
To: informix-datastage@oliver.com
Subject: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
DataStage question.
We need to have 2 instances of Oracle on a Sun box which is also running DataStage at the same time.
On this box we have two projects each of which will connect to the respective Oracle instance. Each project should be completely isolated from the other, apart from the DataStage server engine. (When are we going to be able to run multiple instances of UV?)
Given the the DataStage server engine/unirpc is started with the S99uv.rc script which in turn calls dsenv, which sets up the oracle environment variables etc. How can we change these depending on which project the client connects to.
Regards,
Phil.
Phil,
Although we are using NT, our approach is similar. Every job which connects to our Oracle database has DSN, User and Password parameters (these arent the exact names) which are used by the ORAOCI8 stages.
The other feature we have which helps with this is a routine which compares that parameters of the current job with those of an attached job (we pass the handle from DSAttachJob as a parameter to this routine). Any parameters which have the same name are automatically passed from the current job to the attached job which is about to be started. This saves having to worry about getting all the parameter passing right in the controlling jobs.
(Just for interest, we are running 3 DataStage projects and 3 corresponding Oracle instances on the same NT server).
-----Original Message-----
From: Katherine Lapic [SMTP:katherine.lapic@genmills.com]
Sent: Friday, 5 January 2001 23:29
To: philw@gnosys.co.nz; informix-datastage@oliver.com
Subject: RE: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
Hi Phil,
Were managing this by setting up all of the connection information via job
parameters, then in UNIX we call the jobs from the UNIX command
line. The
move to QA or production requires us to change the parameters within the
shell script when we move to QA. (We have a routine to do this once and set
and use that parameter in all the subsequent datastage jobs.)
Example:-------------------------------------
JOB Params:
oracle_owner: dev
oracle_tns: tns_dev
app_path: /dev
---------------------------------------------
UNIX DEV script:
oracle_owner=dev
oracle_tns=tns_dev
app_path=/dev
#job1
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
#the dsParamString is the list of params and paramvalues
...
# call datastage command line
/opt/ardent/uv/bin/dsjob -server $host -user $dsuserid -password $dspassword
-run -mode $dsmode -rows $dsrows -wait -jobstatus $dsParamString $dsproject $dsjobname 1>> $log_file 2>&1
---------------------------------------------
UNIX Qa script:
oracle_owner=qa
oracle_tns=tns_qa
app_path=/qa
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
# call datastage command line
...
---------------------------------------------
Its not automatic, the UNIX scripts have to be modified (3 lines per
script), but not anything in the jobs. The UNIX params overlay the job
parameters (as long as you specify the param name exactly) when you run the
job. (p.s. disclaimer - I did edit this after cut and past, so this is not
actual executable code).
Good Luck,
Katherine Lapic, Data Architect, katherine.lapic@genmills.com
Enterprise Data Management, General Mills
-----Original Message-----
From: Phil Walker [mailto:philw@gnosys.co.nz]
Sent: Thursday, January 04, 2001 7:40 PM
To: informix-datastage@oliver.com
Subject: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
DataStage question.
We need to have 2 instances of Oracle on a Sun box which is also running
DataStage at the same time.
On this box we have two projects each of which will connect to the
respective Oracle instance. Each project should be completely isolated from
the other, apart from the DataStage server engine. (When are we going to be
able to run multiple instances of UV?)
Given the the DataStage server engine/unirpc is started with the S99uv.rc
script which in turn calls dsenv, which sets up the oracle environment
variables etc. How can we change these depending on which project the client
connects to.
Regards,
Phil.
*************************************************************************
This e-mail and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in
error, please notify the sender by return e-mail, and delete this e-mail from your in-box. Do not copy it to anybody else
*************************************************************************
Although we are using NT, our approach is similar. Every job which connects to our Oracle database has DSN, User and Password parameters (these arent the exact names) which are used by the ORAOCI8 stages.
The other feature we have which helps with this is a routine which compares that parameters of the current job with those of an attached job (we pass the handle from DSAttachJob as a parameter to this routine). Any parameters which have the same name are automatically passed from the current job to the attached job which is about to be started. This saves having to worry about getting all the parameter passing right in the controlling jobs.
(Just for interest, we are running 3 DataStage projects and 3 corresponding Oracle instances on the same NT server).
-----Original Message-----
From: Katherine Lapic [SMTP:katherine.lapic@genmills.com]
Sent: Friday, 5 January 2001 23:29
To: philw@gnosys.co.nz; informix-datastage@oliver.com
Subject: RE: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
Hi Phil,
Were managing this by setting up all of the connection information via job
parameters, then in UNIX we call the jobs from the UNIX command
line. The
move to QA or production requires us to change the parameters within the
shell script when we move to QA. (We have a routine to do this once and set
and use that parameter in all the subsequent datastage jobs.)
Example:-------------------------------------
JOB Params:
oracle_owner: dev
oracle_tns: tns_dev
app_path: /dev
---------------------------------------------
UNIX DEV script:
oracle_owner=dev
oracle_tns=tns_dev
app_path=/dev
#job1
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
#the dsParamString is the list of params and paramvalues
...
# call datastage command line
/opt/ardent/uv/bin/dsjob -server $host -user $dsuserid -password $dspassword
-run -mode $dsmode -rows $dsrows -wait -jobstatus $dsParamString $dsproject $dsjobname 1>> $log_file 2>&1
---------------------------------------------
UNIX Qa script:
oracle_owner=qa
oracle_tns=tns_qa
app_path=/qa
dsproject="proj1"
dsjobname="dsjob1"
dsparamname[0]="oracle_owner"; dsparamvalue[0]="$oracle_owner"
dsparamname[1]="oracle_tns"; dsparamvalue[1]="$oracle_tns"
dsparamname[2]="app_path"; dsparamvalue[2]="$app_path"
# call datastage command line
...
---------------------------------------------
Its not automatic, the UNIX scripts have to be modified (3 lines per
script), but not anything in the jobs. The UNIX params overlay the job
parameters (as long as you specify the param name exactly) when you run the
job. (p.s. disclaimer - I did edit this after cut and past, so this is not
actual executable code).
Good Luck,
Katherine Lapic, Data Architect, katherine.lapic@genmills.com
Enterprise Data Management, General Mills
-----Original Message-----
From: Phil Walker [mailto:philw@gnosys.co.nz]
Sent: Thursday, January 04, 2001 7:40 PM
To: informix-datastage@oliver.com
Subject: Two environments of one machine (QA and DEV)
Sensitivity: Confidential
DataStage question.
We need to have 2 instances of Oracle on a Sun box which is also running
DataStage at the same time.
On this box we have two projects each of which will connect to the
respective Oracle instance. Each project should be completely isolated from
the other, apart from the DataStage server engine. (When are we going to be
able to run multiple instances of UV?)
Given the the DataStage server engine/unirpc is started with the S99uv.rc
script which in turn calls dsenv, which sets up the oracle environment
variables etc. How can we change these depending on which project the client
connects to.
Regards,
Phil.
*************************************************************************
This e-mail and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in
error, please notify the sender by return e-mail, and delete this e-mail from your in-box. Do not copy it to anybody else
*************************************************************************