DSXchange

There should be a lot more output in the director log entry for that call. Could you please post that as well?

What is your exact dsjob command? Try "dsjob -lprojects"; do you get a list of projects?

You first need to identify the bottleneck in your processing. If you write a job that just reads the view into a peek stage what speeds do you achieve - are they the same as when you are writing to Oracle or slower?

The filter works differently, imagine it is as being implemented as "cat {data stream} | {filter command list}". In different terms, the filter needs to be written so it gets the DataStage job data from Stdin and writes the output stream to Stdout.

I would check with your support provider. I just looked through the list of bugs fixed in DataStage V8 Fix Pack 1 and one of them is "Solaris version of ds.rc uses ulimit setting" which can open up speculation that this might be a similar issue to what you are seeing on AIX.

Projects don't use memory, jobs do. I would use one user id per project and then measure system memory by userid at runtime to determine what you are looking for.

340 jobs in a category will significantly degrade Director performance. Try to break that down into several categories (perhaps ~50 jobs per category) and you will notice a significant improvement.

You could do it easily indirectly, just create a sequential file and print it to a PDF document. I am sure that Adobe allows automated PDF creation, but don't know which mechanism is used.

I'm at a loss to explain this, my assumption is that process spawned off user "1" inherit some ulimit settings and that the solution is make sure that the root process has unlimited settings. I have a vague memory of having seen this issue years ago but cannot recall any of the details apart from th...

The dbx and sed error is only secondary to the actual problem in this case, you should concentrate on the Internal Error: (group_.exportSize() <= dbquery->dataBufLength()): db2writeop.C: 985 part. If you change the load method in the stage, does the error go away? In fact, which load method are you ...

An empty string, "" is not a null field. Your schema specifications should read "null_field='NULL'" if I recall correctly.

Can you not edit the sequential file stage and add the newline to Format -> Record Level -> Record Delimiter?

Or, from the command line, use "orchadmin rm {DataSetName}"

Umm, if you are using a lookup stage you should use entire partitioning for the lookup.

If they use Windows and don't have the messaging facility turned off (which I think it is by default, after all those internet exploits), then you can issue the message command from the DataStage process via a shell.