There are three strategies.
One is to use Version Control for DataStage (part of DataStage), which looks after versioning for you. Among other things, it can also look after versioning of associated components, automatically compile in the production environment, and install as read-only.
The second is to use the job version number (in job properties); you can manipulate only the third components, since the major number indicates the release of DataStage, and the minor number the number of times that the job has been "released". Then export from development and import into production.
The third is to use a "deployment package", in which you "release" jobs (the next minor number is automatically allocated), the result is a package that can be installed into development (read-only) using the Package Installer. This approach seems to have lost favour of late, because of the ease of use of Version Control.
Find Version Control on your DataStage CD, and read its manual. Takes about 10 minutes to learn.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
Version Stamping DS jobs
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
vmcburney
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
I find it helps to implement development and testing environments on your development machine. This gives you a relatively clean project in which to test and a place to test that the components are being delivered correctly.
You've got two parts of the delivery process to look at. The first is the physical movement of components. As Ray mentions the version control tool is very good for this as it delivers read only compiled components as well as operating system scripts.
The second part of delivery is the setting of environment specific settings usually held in job parameters. Out of the box DataStage users need to change these parameters manually through the Director. You can use the Parameter Management tool available on this web site or design your own. It is a common practice to store parameters in a central database table or text file and read the values in from a batch or sequence job.
Vincent McBurney
Data Integration Services
www.intramatix.com
You've got two parts of the delivery process to look at. The first is the physical movement of components. As Ray mentions the version control tool is very good for this as it delivers read only compiled components as well as operating system scripts.
The second part of delivery is the setting of environment specific settings usually held in job parameters. Out of the box DataStage users need to change these parameters manually through the Director. You can use the Parameter Management tool available on this web site or design your own. It is a common practice to store parameters in a central database table or text file and read the values in from a batch or sequence job.
Vincent McBurney
Data Integration Services
www.intramatix.com
Shank -
Lots of good information from Ray and Vince. Just wanted to add a little bit of "me too!" to the thread.
*Definitely* look into Version Control. As mentioned, it is free, easy to pick up and learn, and is the best way to move jobs from project to project. Import/export and the dreaded 'Packaging Wizard' are more of a pain to use - and the PW requires root privledges on a Unix box, which usually means you've got to get someone higher up the food-chain to run it for you (not to mention the pain of manually having to move the 'packages' from machine to machine). VC can automate the collection of related objects, batch them up, version stamp everything, compile it and make it read-only in your non-development projects - all from the comfort of your desktop. Gives you a way to roll back problems, too.
As Vince mentions, go with three projects for each of your endeavours: dev, test and production. Keep dev and test on a seperate machine if you can. And definitely parameterize *anything* that would change from project to project or run to run - database names, passwords, file directories, file names, dates, etc, etc. Pulling their values from a stash somewhere is gravy, but setting them once after promotion isn't generally too bad. Typically, the Batch or Job Sequence that strings related jobs together is the only place you need to change the default parameter values, not necessarily on every job you write. If you've got money for a third-party tool, another nod goes to Parameter Manager available from this site - it will help you manage and standardize your parameter usage.
-craig
ps. A 'System Shock' fan, I'm guessing? [8D]
Lots of good information from Ray and Vince. Just wanted to add a little bit of "me too!" to the thread.
*Definitely* look into Version Control. As mentioned, it is free, easy to pick up and learn, and is the best way to move jobs from project to project. Import/export and the dreaded 'Packaging Wizard' are more of a pain to use - and the PW requires root privledges on a Unix box, which usually means you've got to get someone higher up the food-chain to run it for you (not to mention the pain of manually having to move the 'packages' from machine to machine). VC can automate the collection of related objects, batch them up, version stamp everything, compile it and make it read-only in your non-development projects - all from the comfort of your desktop. Gives you a way to roll back problems, too.
As Vince mentions, go with three projects for each of your endeavours: dev, test and production. Keep dev and test on a seperate machine if you can. And definitely parameterize *anything* that would change from project to project or run to run - database names, passwords, file directories, file names, dates, etc, etc. Pulling their values from a stash somewhere is gravy, but setting them once after promotion isn't generally too bad. Typically, the Batch or Job Sequence that strings related jobs together is the only place you need to change the default parameter values, not necessarily on every job you write. If you've got money for a third-party tool, another nod goes to Parameter Manager available from this site - it will help you manage and standardize your parameter usage.
-craig
ps. A 'System Shock' fan, I'm guessing? [8D]
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Shodan
If you are having problems finding Version Control ... it's possible you are using an early release, 4 or even early 5 releases didn't ship with VC on the CD. You must contact your DataStage reseller/or Ascential directly to receive the authorization codes for those releases.
Second, I need to thank my friends here, Ray, Vince and Craig for mentioning Parameter Manager. If you haven't seen the latest material on it... we set up a new tutorial at www.DataStageXchange.com/PM/ hope to see you all there.
Editor of DSX.
If you are having problems finding Version Control ... it's possible you are using an early release, 4 or even early 5 releases didn't ship with VC on the CD. You must contact your DataStage reseller/or Ascential directly to receive the authorization codes for those releases.
Second, I need to thank my friends here, Ray, Vince and Craig for mentioning Parameter Manager. If you haven't seen the latest material on it... we set up a new tutorial at www.DataStageXchange.com/PM/ hope to see you all there.
Editor of DSX.
[?]Forgive me for inserting a question in this thread...
...but I just wanted to clarify that DS Version Control will
successfully promote between projects (UAT -> Prod), when the
projects reside on seperate machines? We are considering using
DS Version Control, and that is a requirement which should be met.
Thanks in advance.
Ed
...but I just wanted to clarify that DS Version Control will
successfully promote between projects (UAT -> Prod), when the
projects reside on seperate machines? We are considering using
DS Version Control, and that is a requirement which should be met.
Thanks in advance.
Ed