DSXchange

There is no difference between versions. Newly created jobs don't get a //PURGE.SETTINGS record in either version. The only thing that creates the //PURGE.SETTINGS record is someone manually overriding the default settings in Director client.

In an Upsert scenario, each individual update may take some considerable time (in database terms). If you send 5000 before you commit, that wait time is multiplied and seen as a performance degradation (for example because rows/sec goes down - the clock keeps running but no more rows are being proce...

In my case I got a requirement to delete dataset segments which has names such as PX_BEA.ds.dsadmin.DEV.0000.0000.0000.65e7.cf771bfe.0000.b324c6a7 located in is/node1/dataset. Resist stupid requirements! Never delete part of a Data Set. Delete it all, using the Data Set management tool or the orcha...

Use a concatenated list of values and the Field() function to retrieve the individual values.

Before we can advise on the command(s) we need to know what "flavour" of UNIX you are running - for example AIX, HP-UX, Solaris, Red Hat Linux, SuSE Linux, and so on. They're all different!

You should be able to use the new Migration Assistant, since you've done no work at all (and you're on version 8.5).

I'm not aware of any memory settings that can be made in uvodbc.config. Can you be more specific?

Sounds like a severe case of block overflow (check the Director log for messages about this). Can you add one or two more blocking fields?

You see multi-instance jobs in Director particularly in Status view. Multi-instance jobs have a dot and invocation ID at their end. If no invocation ID was specified, the dot is still there.

How long does the job take to start under each circumstance?

A knot is one nautical mile per hour.

I have not encountered the term in more than 12 years' experience with DataStage.

The //PURGE.SETTINGS record is created by someone manually overriding the default purge settings. Obviously this has not been done to this job in the new environment.

Create a routine. Call the routine from a stage variable. Load all the columns into a dynamic array and have the routine sort the dynamic array. Unpack the dynamic array into the output columns. Easy!!! Here is an example of such a routine, which produced the result you indicated. FUNCTION SortDynam...

Certainly. Check this link for details.

All inputs to one Join stage must specify the same join key. If the join key is changing, use cascaded Join stages.