We are going through an effort to clean up our DataStage environment before undertaking our next big development push and one of our issues is that everyone interpreted our naming standards differently . We would like to go through and rename these jobs to follow our naming standards. We have created a spreadsheet with the old and new names and would like to script out a method to do a massive rename.
My current idea is to:
1) Dump the project to a DSX file.
2) Run a Perl script to rename the jobs.
3) Import the new DSX file.
4) Recompile all the jobs
Is there any other approach that would be better?
Shawn Ramsey
"It is a mistake to think you can solve any major problems just with potatoes."
-- Douglas Adams
What about your job control? Any issues there? Otherwise, your plan seems reasonable.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
We are going through an effort to clean up our DataStage environment before undertaking our next big development push and one of our issues is that everyone interpreted our naming standards differently . We would like to go through and rename these jobs to follow our naming standards. We have created a spreadsheet with the old and new names and would like to script out a method to do a massive rename.
My current idea is to:
1) Dump the project to a DSX file.
2) Run a Perl script to rename the jobs.
3) Import the new DSX file.
4) Recompile all the jobs
Is there any other approach that would be better?
That's not a bad method. I'm not sure how many jobs you are dealing with or if you have reusable Perl code for this task, but as painful as it sounds, a manual process of find/replace in wordpad (helps to have a NT workstation with a good amount of RAM) or a similar manual process on the UNIX side should work with little room for error.
Don't forget that renaming jobs affects any job control jobs and sequencers calling jobs with the old name. This also might be a good time to import the new dsx you create to a new project, at a mininum for testing, but possibly as a cleanup method as over time there ends up being many unused hashed file and table definitions in the repository that never go away
No way. I think this is very dangerous. There is a product called DsToolBox on http://www.teknion.net designed to do exactly this. I have never used it but I think it is a lot safer way to change all of these jobs.
Also if your parameters are inconsistant then I would get Parameter Manager. It can quickly standardize your parameters. These products are not expensive and could easily pay for themselves on this project.
This depends how your project is designed.
The main issue somes with the Sequencers.
You need to build/edit those sequencers again.
We never tried this before ( renaing with script on export file)..
I suggest to go manually and replace the names with convensional names.
Tnks
Neena
shawn_ramsey wrote:All,
We are going through an effort to clean up our DataStage environment before undertaking our next big development push and one of our issues is that everyone interpreted our naming standards differently . We would like to go through and rename these jobs to follow our naming standards. We have created a spreadsheet with the old and new names and would like to script out a method to do a massive rename.
My current idea is to:
1) Dump the project to a DSX file.
2) Run a Perl script to rename the jobs.
3) Import the new DSX file.
4) Recompile all the jobs
This depends how your project is designed.
The main issue somes with the Sequencers.
You need to build/edit those sequencers again.
We never tried this before ( renaing with script on export file)..
I suggest to go manually and replace the names with convensional names.
Tnks
Neena
I have just gone through a similar process with a bunch of Perl scripts and it worked fairly well so I feel comfortable with the code for the global search and destroy. In addition we are using a table driven automation process for the jobs themselves so the issue with sequencers in moot.
I will take a look at the tools mentioned by others but I think I will test this approach. Maybe even in production.
In case my boss is reading this, I was only joking about the production thing. :D
Shawn Ramsey
"It is a mistake to think you can solve any major problems just with potatoes."
-- Douglas Adams
I've successfully done things similar to this with Perl scripts. But if you are simply doing a global find'n'replace, sed or awk would probably work as well.
Having said that, there's always the risk with global s'n'r that your find pattern may have an undesired match. You should make sure that the pattern is as specific and restricted as possible.
You could export the jobs as XML. There are some nice Perl libraries that work with XML documents, that would allow you to search and modify specific job elements in the XML by name. Of course, you have to determine what elements you want to change.
A changed element log is a very good thing to have.
What are you using for DS version control?
You'd want to do a regression test after any changes anyway, no matter what tool you use.
Your solution is solid if you limit your search and destroy to jobs. In either the xml or dsx the identifier and name are what you need to be concerned with. The name of the job is not in any other tag and if it is, it is probably a comment. The name of the "job" is always in the ROOT record of DS_JOBOBJECTS.
I have a toolkit with BASIC, Perl, C and DS jobs that do exactly what you desire and have never had an issue. It only becomes a bit more complex when you throw other types of objects in the mix.
. We would like to go through and rename these jobs to follow our naming standards. We have created a spreadsheet with the old and new names and would like to script out a method to do a massive rename.