DSXchange

The "dscapiop.o" library is in the "/DSParallel" subdirectory and is a library object, not an executable. If you revert your changes, does the job work again? (My feeling is that the two aren't directly related)

There should be more to the error message than that. Perhaps you have a permissions issue - is the compile problem just with this one job or with all jobs?

As mentioned earlier, your heap size for the lookup stage is too big. Either reduce the data size (use unbounded VarChar() and/or less columns) or use the suggested method to increase the runtime object's virtual memory space.

The internal hashed fiiles / tables such as DS_JOBS and the RT_STATUSnnn file are not documented by IBM so there will be little help forthcoming there, albeit a search of DSXchange will give you a lot information. The correct way of getting the status is to use the DSGetJobInfo() routine instead of ...

Please use "Please" instead of SMS "plz".

Add a before-job call to execute the shell command "ulimit -a" to your job.

Yes, you should use the command activity to run your batch outside of DataStage.

It is indeed MAXKEYSIZE in the uvconfig file.

The sale of U2 is an interesting one; while IBM didn't put a lot of effort into the U2 products they certainly didn't sweep them by the wayside, either. I look forward to seeing what Rocket can and will do with the systems, whether they just milk a cash cow for whatever can still be gotten or if the...

What COBOL picture does this column have, "numeric" is not a cobol type. Spaces are not a valid number.

did you check the HFC utility documentation as suggested? The minimal syntax for mkdbfile is: mkdbfile {HashedFilePathAndName} {type} {modulus} {separation} type 30 (dynamic) files have a different syntax: mkdbfile {HashedFilePathAndName} 30 {MinModulus} {GroupSize} {HashType (20 for General, 21 for...

Either pre-sort your data to reduce the required scratch sort space, or increase the size of your scratch disk or add additional scratch disks to your APT_CONFIG file for that run.

Execute command stage.

this type of checking is best done in a job sequence. From there, you can call the UNIX command "wc -c {yourfile}", then parse the returned string using "FIELD(TRIM(Execute_WC_stage.$CommandOutput),' ',1)" to get the number of characters. Then, if that value is 0, don't call your...

I bet your PX job has the datatype "VarChar" for this column. Declare the type as numeric in your job and perform an explicit conversion in PX.

Without monitoring it as Ray suggested you will, of necessity, have very imprecise measurements. Since DataStage PX starts many interconnected processes, some of which might have very short "lives", any snapshot you take of system load will not necessarily be indicative of what the machine...