I'm trying to work out an effective way to deploy my datastage jobs. i've looked at the package wizard and have deployed a job, but it seems that
Routines, Table Definitions and Shared Containers are over looked. am i missing something here. but i assumed they would be picked up as dependencies.
Michael, from my perspective, I do not use the packaging wizard. I prefer a good old fashioned written technical specification to cover documenting a migration set. I find the packaging paradigm in DataStage to be more of a "shiny object" or sales "bullet item" than anything else. It is old and clunky, and not full featured. DataStage has trouble keeping track of metadata imported into jobs.
I have advocated to Ascential modifying the job properties to include a revision history notation box, whereby as developers we could internally document a code change. Since this property box would be in all jobs, routines, table definitions, containers, etc, it should be easy to modify the export wizard to grab objects by a "case number". For instance, an enhancement I need to do involves a function, 3 jobs, and a table definition. The case is assigned a number, and when I go into the respective objects I note them as revised under that case number. When I do a an export, I choose to export by case number, and thereby pick everything up. Rather simple and self documenting. If you've ever had to manually pick objects (1) at a time to export you know how frustrating this can be.
Since my suggestions never went anywhere, I've been using the Long Description property box in the objects to more or less track revisions. Each line is used per revision, and I put a formatted string there, something like "Version Number | Revision Date | Developer Name | Case Number | Description". I then use a simple script I wrote than parses a ".dsx" file that I cut of the whole project. This script explodes the dsx into many files, (1) per object (jobs, routines, definitions). I wrote another script to collect objects by looking at the Long Description for a case number and building a concatenated ".dsx" file. A little crude, but manageable.
Another thing to consider is looking at one of the QAD (quick and dirty) reverse engineering utilities ("JobDatabaseExport") I have posted on the Exchange. I wrote it to export the job design database into a relational form. Several of the output files, when loaded into a table, can construct most of the dependencies you need. For example, all routines/functions in use by a job design is produced by this utility.
My suggestion would be to consider deploying using DataStage's Version Control application. You should be able to find it on the install CD in the Version Control directory. It basically provides a repository to store versions (coding iterations) of all DataStage components and its benefits include providing a history of coding changes, ensuring against loss of code changes, and a platform for deployment.
The versioning process allows you to assign specific releases to your jobs (or other DS components) and can automatically capture certain job dependencies. Version Control provides several sever deployment options including setting the read-only state, job and routine compilation, etc.
