DSXchange

Hi,

Is there any command line utility in datastage to move parallel jobs from one folder to another within the same project(even cross project)?

Reason for not doing it manually: There are ~ 200 parallel jobs to be moved, hence I'm thinking of creating a Unix script to automate it. However, I didn't find any utility(CLI command) to do so.

Requirement: This is a housekeeping activity to cleanup the Production project from any unwanted jobs

Way I want to implement:
Create a shell script that reads a pipe delimeted file containing the following details(in the same order)

Field#1: Source_Project(where the job lies)
Field#2: Job Name(name of the job to be moved)
Field#3: Target_Project(the project where the job is to be moved)
Field#4: Target_Folder(folder within the Target_Project where the job is to moved)

and MOVE the job accordingly.

Please help.

Thanks.
Kumarjit.

I'm not aware of one and there still doesn't seem to be any such capability even in the latest Command Line Interface documentation.

Moving jobs between folders in the same project is a simple drag-and-drop operation from what I recall. As to 'moving' them from one project to another, seems to me what you'll end up doing is exporting them from the source project, importing them into the target project and then (once confirmed) deleting them from the source project. While the first two (minus the confirmation) can be scripted, not aware of any way the delete can be. Perhaps a check with your official support provider is in order? While I'm sure there are ways to do things like this directly manipulating the repository, I can't imagine any of them are officially sanctioned.

In my personal experience when you've got something like this, something that seems like a one-time need rather than something you'll be doing over and over, in the time spent working out some automated mechanism you could have done the manual work. Sometimes several times over. Been there, done that, got the t-shirt.

As Craig has mentioned, you can multiple select Jobs in the designer client and drag-and-drop them to another folder. The only drawback is that only items can be moved and not directories or directory trees.

I just completed a total restructuring of the folders in a project with more than 600 design objects -- sequence and parallel. I did it manually, knowing that any other method had some risks for the project integrity.

I started with documenting the old structure, and linking old folders with new folders. I discovered that some objects didn't have a one-to-one path to follow.

The one alternative I looked at -- and discarded -- was exporting the design objects to a dsx file and editing it with find/replace. Editing the dsx is risky under any circumstances.

I forget who the author/creator was, but there is a utility out there called DSX Split. If you can find it, it might provide a more secure (less risky) way to edit the dsx file.

Well... for what it's worth, the discussion and code for a DSX cutter/splitter is in this old post.

I would manually hand-select and export the jobs of interest to a dsx file and do a find/replace on the folder/category names then import into a new project. Not much risk there. I would not think to automate such a thing unless there are plans to repeat the same type of activity numerous times.

I used to think that same "not much risk there" thought. Then one day I goofed up editing a folder or category in the dsx file... forget what exactly, I think I may have accidentally removed a "/" from "///" or at least that's all that is left of my memory of the incident. Well, that and the sudden panic when I imported the dsx and corrupted the entire project.

Our backup was old enough that we didn't want to use it except as a last resort. Thankfully I was able to work with the awesome Karen Powers to hex edit the project back to life!

She has help many many a time over the years too.

If you do go that route, make sure to import into a new project, as in newly created and empty, in order to lower the risk. Importing back into the same project would certainly be riskier! But I'm not against it, as I've been doing that way myself since '99.