DSXchange

Migration from a Server environment to a PX Environment is simple and almost automatic, as the PX product also includes the Server components.
The difficulty lies in changing those Server jobs to PX Jobs; this step is not automated and requires a lot of work to do correctly.

I recall that the executable can only be specified via the front-end tool, not from the command line.

filter and use "head -1" and "tail -1".

The database schema is usually defined using a job parameter so that the value can be changed at runtime. This should be the only place where you need to change anything.

It would seem that you have unmatched quote characters. What have you defined as your quote character and could you post a line of data that causes the error?

In server jobs this can be done in several ways, I would do it with a transform stage followed by a named pipe. The stage variables would be IsLabel = IF In.ColumnData[1,2]='07' THEN FIELD(FIELD(In.ColumnData,'"',2),"'",1) ELSE '' OutputString = IF IsLabel THEN EREPLACE(CollectionString,@FM,',"':IsL...

I doubt that the Administrator will have any better fate than the other 2 clients.

If you look into the project directory, do you see a VOC file and a DS_JOBS file (I assume the "DSR_JOBS" was a typo)?

There is no functionality to do this straight out of the box, particularly from the command line. One option is to do a full project export into a .dsx and then to use a tool such as sed or awk to parse out the relevant job names and datasets; that won't take much effort.

Being able to access the DBA_EXTENTS is very different from being able to extend them; this is an Oracle issue that needs to be addressed by your DBA. An alternative if the extents are large enough is to reduce your transaction sizes so that this space does not fill up.

Is the file there? It should be. Perhaps you don't have sufficient access to it as your userid.

What is your definition for "instl_date"?

Hashed files default to Dynamic (Type 30) files. This means that when growing they need to "split" and this overhead can cause slowdowns. Also, the method used to display rows/second depends upon buffering and is notoriously misleading during runtime. If you know approximately how many records your ...

That might mean you have orphaned processes and/or locks. I always recommend that the deadlock daemon is started in order to have an automated cleanup happen when processes are killed or stopped, you can read on how to do that in many places in this forum. If your system is not busy with users, you ...

Ray, I bet you spent some time waiting for an errant query to complete recently.

I'm not at a system with DataStage right now so cannot confirm, but perhaps your initial value cannot be converted to a timestamp and it just happens not to be used with the test data. How about trying "12/31/9999 12:00:00" (or is the default format ymd, I can't recall or check).