Adding description to jobs

[pavankvk]

Is there any way in dataStage where we can change the repository information in backend as in informatica

In one of our project , the requirement is to add the description in all jobs (there are 500 + jobs ).

Now instead of open each job and then add description in it, can we do something directly in the repository so that we can save time on it .. ( We have tried to do the same on dsx of a sample job and again reimport it after adding the description and it is working. But it may definitely take time ).


Is there a better way

[akhiln]

Yes, You can do that using any of the programming languages like PERL, C etc.

First export the jobs(only Job Designs) you want to change the descriptions. Then write a PERL script which will take this dsx as the input file and whereever you find the keyword "FullDescription"......give your appropriate descriptions.

[kduke]

I posted a routine called KgdFixLongDesc. It is also on my tips page. You need to modify it to meet your needs. There is another one for routines called KgdFixLongDescRtn. You need to write a job to select all jobs and feed them to this routine one at a time.

[chulett]

It's going to be a manual effort in some fashion, as I doubt all 500 of your jobs will end up with the same description.

Rather than going through the effort of a full export / edit / import, I've found about the least painful way to update job descriptions is via the Manager. If your double-click option is set to 'Properties' use that or you can right-click and select 'Properties' to have quick access to the job's properties panel. Update the description and click ok. Lather, rinse, repeat.

[kduke]

It will look something like this:

Code: Select all

Job: KgdCopyParamJob 
------------------------------------------------------------------------------------- 
Non-technical description: 
Change DSN from DSNParamName, UserParamName, PwdParamName 
in FromJobName to ToJobName only if DSN2Change = "value". 
The idea is you are moving from dev database to test database. 
------------------------------------------------------------------------------------- 
Business rules: 
Be careful this job updates DS_JOBOBJECTS 
------------------------------------------------------------------------------------- 
Rules for restarting this job: 
na. 
------------------------------------------------------------------------------------- 
Parameters: 
1. FromJobName 
2. ToJobName 
3. DSN2Change 
4. DSNParamName 
5. UserParamName 
6. PwdParamName 
------------------------------------------------------------------------------------- 
Sources: 
FromJobName 
------------------------------------------------------------------------------------- 
Targets: 
ToJobName 
------------------------------------------------------------------------------------- 
Modification History: 
------------------------------------------------------------------------------------- 
UserId Date Version Modification Description 
------------------------------------------------------------------------------------- 
kduke 07-06-2004 1 Created job. 
------------------------------------------------------------------------------------- 

[chulett]

Kim, am I missing something? Won't that put some sort of basic boiler-plate description into all the jobs?

I suppose you could modify it to pull the description from some sort of generated list keyed to each job that someone typed up, otherwise it's just plain old IMW - Iterative Monkey Work - that will need to be done. And seriously, if you are gonna do it by hand, doing it via the properties in the Manager is the best way I've found to do that.

[vmcburney]

Part of your problem when adding descriptions may be understanding what the job is really doing. My vote for the fastest method for screening the job and adding a description is to generate full HTML documentation using the dssaveasbitmap script posted on devnet. Allocate them to whoever is doing descriptions. Open up the html job report with the bitmap in it, have a guess as to what it's doing and then use Manager to double click on the job properties and change the description.

Opening up html job reports in a browser is a lot faster then opening up a job in Designer and the bitmap can be clicked on to jump to properties such as table names and derivations, also faster then doubleclicking on properties in Designer.

[kduke]

Craig

You are correct. This is used to meet some kind of standards. Mainly mine. I do like the fact that the parameters are ll named. I also like that the source and target tables are listed but that means you have to manually update the long description.

I agree with Vincent but we always use an annotation with the long description. That makes this more useful because I hate to open properties to see the list of parameters and the stages to see source and target tables.

Functions makes this more useful because almost nobody documents their functions. I tend to copy these into the code. I do this on batch jobs as well. I save these in text files because I prefer Editplus over the editor in DataStage. This also allows me to go back a release because DSX's are not backward compatible.

All of these are shortcuts because I hate to document. So automate it. that is why I created DSaveAsBmp and GenHtml to help automate documentation. These routines help the automated documentation to look better and more complete.

I would like to see really nice organized job designs. I propose that if you think you have a nice designed job then post it on ADN and mark it Pretty Job Design. Let us vote on whose looks the best. Ray has the nicest designs I have seen. I would also like to see a DSX posted with each stage type. One job per DSX example. This would be a great learning tool. Let us pick the best of the best and reward the best some how. Maybe FAQ could point to the best example of each stage type. If we don't want to use ADN then maybe they can email me the DSX files and I will post them on my tips page.

[ray.wurlod]

Descriptions should always go in first.

"Later" never comes.

I will shortly post a brief essay on the process of job design. It begins without any software (yes - planning!). The very first thing to go into a job design is to add short and long descriptions. The long description is probably a lift from your planning document, and contains enough information that another developer taking over the design has enough idea of your intentions that there is no need to start again from scratch.