MOVING DS JOBS

nag0143 · Post by **nag0143** » Thu Feb 05, 2004 12:05 pm

I have done all the development in R3DEV AND NOW I NEED TO MOVE ALL THESE JOBS TO R3QA ..... DO I NEED TO CHANGE THE PATH IN ALLTHE JOBS BUT THERE ARE HUNDEREDS OF JOBS ..... IS THERE ANY OTHER WAY ...EASY WAY....

kcbland · Post by **kcbland** » Thu Feb 05, 2004 12:22 pm

Are you talking about a hardcode directory path in the job designs, in places such as the sequential file name?

The answer was use a job parameter that is switchable according to the environment you're in, and pass the value in using job control. The next answer is embed the default value along with the job parameter. Then, use a mass parameter default update utility like Parameter Manager to mass deploy a default change.

If you didn't use a parameter, then you have few options. You could text search/replace inside the .dsx file the change.

nag0143 · Post by **nag0143** » Thu Feb 05, 2004 12:37 pm

Thanks kc...since i guess its too late to use parameters i can do mass change by find/replace on .dsx..

chulett · Post by **chulett** » Thu Feb 05, 2004 1:44 pm

At this point it is not too late as everything is still in your dev project. Bite the bullet and modify the jobs to use Job Parameters for anything that could change from environment to environment.

What are you going to do when this rolls to production? Do this all over again? What about the maintenance of these jobs? Constantly re-edit the dsx to make all of the appropriate changes?

Don't even think about it. Go back and make the change, there will be some pain now but you'll be much happier later.

kcbland · Post by **kcbland** » Thu Feb 05, 2004 1:55 pm

You can tell that I must be sick because I didn't lecture. Thanks Craig!

ray.wurlod · Post by **ray.wurlod** » Thu Feb 05, 2004 3:35 pm

Another vote for "do it now". There'll never be a better time. There was, but it's gone.
Parameters buy you insurance against things that may change over time or between environments, such as pathnames, data source names, passwords, WHERE condition constants.
Best practice is to have default values point to your development environment (so you can't accidentally damage your production environment), and to have default values for passwords not being valid passwords at all (so that anyone using the system must provide a valid password).
And make sure you use Encrypted as the type for password parameters, and Pathname as the type for pathname parameters. In the second case it means you automatically get a browser when being prompted for the pathname. I've also found that a List type for data source names provides a measure of idiot-proofing too.

peterbaun · Post by **peterbaun** » Thu Feb 05, 2004 5:12 pm

Hi -

Not that my input has anything to do with this matter - it is just a curiousity. Even though you use encrypted for the parameter containing the password you can easily decrypt it by making a job with
some source --> transformer --> flat file
(having at least one row going through this transformer) and enter the password parameter in a derivation field. It will acutally write the encrypted password in readable letters (at least in DS version 5 and 6 havent had the opportunity to test this in version 7).

Regards
Peter

ray.wurlod · Post by **ray.wurlod** » Thu Feb 05, 2004 6:36 pm

peterbaun wrote:Hi -

Not that my input has anything to do with this matter - it is just a curiousity. Even though you use encrypted for the parameter containing the password you can easily decrypt it by making a job with
some source --> transformer --> flat file
(having at least one row going through this transformer) and enter the password parameter in a derivation field. It will acutally write the encrypted password in readable letters (at least in DS version 5 and 6 havent had the opportunity to test this in version 7).

Regards
Peter

Ssssshhh!!!

It's a known issue.

Teej · Post by **Teej** » Fri Feb 06, 2004 1:00 pm

Another known issue:

You use Oracle in PX for 6.x? Just for fun, check out the scratch directories, and look for ora*.par files. Whoops, password is visible.

Haven't test it with 7.0.1 to see if they fixed my open issue.

-T.J.

ogmios · Post by **ogmios** » Fri Feb 06, 2004 1:20 pm

Teej wrote:Another known issue:

You use Oracle in PX for 6.x? Just for fun, check out the scratch directories, and look for ora*.par files. Whoops, password is visible.

Haven't test it with 7.0.1 to see if they fixed my open issue.

-T.J.

The DB2 Bulk Load Stage has the same problem, on the other hand since it's so easy to decrypt DataStage encryption I sometimes wonder why I bother encrypting passwords.

Ogmios