DSXchange

The two concepts are very different. Multiple instances means that the same job can run multiple times in parallel, while the parallel nodes in a PX file define how many nodes the data is partitioned into during a run of a single job. Shared Containers don't come into the equation at all.

What are your environment ORACLE settings? Particularly NLS_LANG. If you set that to a UTF set then your source database data will be converted to UTF when read, and your write should correctly load your data.

Let's assume you have a file:

What happens when you click on the table name and select "Select Table"?

The error is a null pointer somewhere in the program. That makes it more difficult to analyze. Does the error occur immediately or after running for some time? Does it make a difference if you split the large XML into separate files?

In a case like this it would be best to post the whole unedited error message as a quote. Also, to which database are you going via ODBC?

It looks symptomatic of a bad library in the patch. I think only IBM can help you here.

Could you explain what you mean by "table name"? Do you mean a parameter value, a constant value coded into your buildop, or something else?

how did you verify the ulimit value? The only way that yuo can really do and know what the current value is , is to put a before-job shell call into your job to list the job's actual runtime value.

Go to the stage before the one you are getting the warning for, then edit that stage and set the stage advanced output properties to "clear".

jacksamsula wrote:(DSGetJobInfo) Failed to open RT_STATUS228 file.

?

I just went over the rest of the code. It won't run at all, and it cannot have ever run. Although slight changes would make it work, try: OPEN '','DS_JOBS' TO DSJobsFilePtr ELSE CALL DSLogFatal('Unable to open DS_JOBS file, status is ':STATUS(),'') SELECT DSJobsFilePtr TO 1 Finished = @FALSE READNEX...

That means that there are 6 entries (or jobs) in your DS_JOBS file. Thus the outer loop executes for each job, then the code retrieves the corresponding job number for using the substring/extraction. The string has a pipe symbol to denote the name and the data part, thus the FIELD(JobList... Hmm, I ...

I'm not sure what could be the cause here, since the OPEN for a hashed file shouldn't time out. The "-99" is not a valid return code for the OPEN command so I don't know why the open would fail.

I don't know what could be causing your problem. I still think it is related to the cpp compiler, though. Do those jobs that take longer have inordinately more transform stages than those which compile quicker?