DSXchange

1) what is the use UV(Universe) in DataStage The underlaying database of DataStage used to Universe. Its not Universe anymore (Since 5.1 I believe). Its called DataStage Engine. I think its safe to say that due to the similarities in the architecture, uv commands can be run on DSEngine. I might be ...

Or go inside your Administrator and simply type the command

If the hashed file is a pathed hashed file, then create a VOC entry using SETFILE command and use that VOC name as the hashed file name.

Stick in a -wait along with -jobstatus to observe the behaviour. As noted, it very well may be a bug.

Use CONVERT() function to convert every character thats not numeric to an empty space. Something like CONVERT("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~!@#$%^&*()_+=-,./;[]\|}{:?><","",in.COL) You can add any character that i left out in ...

Refer here.

Is'nt that a server routine? If your looking forward to using it in a px transformer, then dont. Its not available for px transformer. You will have to either use a server job or a basic transformer in a px job if you want to use that routine. But there are px transform functions that can do the sam...

Specify an order by in your sql or use an explicit sort stage to sort the data. Let the aggregator know how the data is sorted.

Good idea Vincent. That springs another idea in my mind. Change each letter in the type column to its ascii equivalent. Use that as a surrogate key. That will be always the same. This way you dont even have to maintain a key lookup dataset. I posted C code a while back to do that. Check it out.

No, it wont. It will only add an extra step of generating keys for the new items everytime and appending it to your dataset/file/table that contains the item and key.

It might be. Check the length and precision and specify that manually for the key field within datastage. See if the behaviour of your job changes.

For now it maybe. As for the future, no one knows. The best design would be to handle that with minimal to no change to the present design. Thats why I advised a multi-instance job. Your method will work too.

So everytime there will be the same set of records right? Then its even easier. As for how to, no function out of the box, basically you will have to generate it. vmcburney has an FAQ entry on it. Click here.

Only the keys.

Read is fine, very fast too. A multiple instance job can keep it scalable. Tomorrow if a fourth or even fifth table comes in, no job design needs to be changed. The same can work for x number of tables.

Get the item and generate keys using the transformer. Load it into a dataset. Each time you load your data, do a lookup on this dataset to get the exact key everytime. If there are new ones, send it down a second link and generate the next key. You can certainly design it along these lines to do wha...