DSXchange

I am working on a job where the user would like to choose one or multiple selections from a list of locations and then have the parallel job run through the locations they choose. Is it possible to do this with a list parameter? If not is there a way to do this?

The job is gathering information on membership card customers at our various locations. Right now it is running through all 19 locations, but the users would like to be able to select locations from list and have the job run on the locations they choose.

Any advice would be greatly appreciated. Thanks...

The datastage job will run with whatever YOU pass it as a parm.

You're talking about a pre-datastage parameter selection script/webpage/program/pop-up gui.


There are so many ways to do that, but it all boils down to you passing a parm to an existing job. Sounds like a multi instance job at that.


If the user is selecting a location... does he expect data back in some type of interactive fashion? If so, you could do a REST API interface to a WISD job.

If not, then simply go with your preferred GUI program, select from a pre-ordained list of locations, pass the selection to datastage via a parm.

The built in List parameter type lets you hard-code multiple values, but only allows you to choose a single value at run time. A related disadvantage of that approach is that any time a location is added or removed, you have to re-hard-code the values, re-compile the job, and perhaps have to re-promote it through your dev/test/production environments.

The question then is how to allow a user to select one or more values from a list at run time. Is that correct?

Just curious, are the users logging into DataStage to run these jobs or are there other user interfaces or tools involved?

I would probably be inclined to somehow (as Paul alluded to) use a pre-job or some other user interface to build a selection set--a text file or records in a database table--then use that location as the first stage in the parallel job, or as a lookup stage, depending on what the job deos. In that case you wouldn't need to fool with parameters.

The notion of a user "controlling" a production job scares me more than a little bit. I hope you have controls over that which would prevent a user from creating a mess.

In our environment, I'd use Control-M to pass the location(s) to the DS job. For example, I'd create a variable called LOCLIST, and make it subject to an override/edit at runtime. That's not a user interface, someone in an operations unit would have to do the editing. That would fulfill my control over what the user could do.

LOCLIST would then be passed as a parameter on the DS command line. Coding to accept and use it would be up to you.

A simpler approach, would be a text file containing the location list, which can then be read cyclicly in the job. The user would create the text file and have it placed in the path you determine for it.

The List parameter type allows at most one item to be selected from the list.