Hi
I am having problems after migrating the code from one datastage instance to another.
I have a unix script that passes all the required parameters for datastage including database userids and passwords. Whenever I change to the new instance the new database instance I am using is getting locked. I donot know the reason why it is doing it eventhough I supply the correct DB parameters through my shell script.( I know this because a few jobs before the sequencer are running fine with the new DB parameters). I have to manually run each job in the sequencer to success and then finally run the sequencer.
The questions I have are
1. Does importing job executables carry the previous instances user ids and pwds.
2. How do we know that datastage sequencer is getting the right userids and pwds before actually running the sequence.
3. Do we have to change the DB parameters in all the jobs of the sequencer for every migration.
4. What are the standard procedures followed after migrating code from one instance to other.
Flowchart of the process is :
Pass unix parameters-->run presequencer jobs(runs fine)-->run sequencer (problem here)-->end
Please inform.
Thanks
code migration problems
Moderators: chulett, rschirm, roy
1. Sort of because you may have defaluts on the parameters. I have seen where the parameter name was TargetDSN and they used TargetDsn at run time in a script ans also in a sequence and the proper value was never sent because the parameter name was invalid.
2. You don't. You can check the log afterwards to see what was used. This is also why I store parameter values in ETL_PARAM_HIST which is part of EtlStats.
3. No. Parameters are usually set by the first batch or sequence at run time.
4. Most use exports and imports. A better solution is Version Control supplied by ASCL.
2. You don't. You can check the log afterwards to see what was used. This is also why I store parameter values in ETL_PARAM_HIST which is part of EtlStats.
3. No. Parameters are usually set by the first batch or sequence at run time.
4. Most use exports and imports. A better solution is Version Control supplied by ASCL.
Mamu Kim
-
Sainath.Srinivasan
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
As long as you can the jobs manually with success, there must not be anything that prevents you to do so from a sequencer.
You can try to identify the tables having the lock with the corresponding user-ids who hold them. It may be that the db is hit by other applications that may cause this contention.
Ask your DBA to monitor the db performance when you execute your jobs and sequencer.
You can try to identify the tables having the lock with the corresponding user-ids who hold them. It may be that the db is hit by other applications that may cause this contention.
Ask your DBA to monitor the db performance when you execute your jobs and sequencer.